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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a system and method for securely utilizing 
Basic Input and Output System (BIOS) services. 

2. Description of the Related Art 

In virtual memory subsystems, "virtual" memory addressing is employed in 
which the memory addresses utilized in software programs are mapped indirectly to 
locations in physical memory. Translation to physical addresses is typically 
accomplished by the processor, and such physical addresses are inaccessible to user 
mode software and the Basic Input/Output System (BIOS). 

One example of such virtual memory subsystems is that used by Windows 
NT, which is manufactured and marketed by Microsoft, Inc. In particular, Windows 
NT incorporates a demand-paged virtual memory subsystem. The memory address 
space provided to a program running on the Windows NT operating system is 
safeguarded from other user mode programs just as other programs are protected 
from it. This ensures that user mode services and applications will not write over 
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each other's memory, or execute each other s instructions. Kernel mode services 
and applications are protected in a similar way. If an attempt to access memory 
outside of a program's allocated virtual space occurs, the program is terminated and 
the user is notified. Virtual memory subsystems also prevent direct access by user 
5 mode software to physical memory addresses and to input/output devices that are 
part of a computer system. 

There is an increasing trend towards the use of input /output devices on a 
computer system which are capable of executing operating systems using virtual 
memory subsystems. In such systems, there is no means for accessing memory 
10 n outside of a program's virtual memory space, such as BIOS functions. One approach 
H to this problem is to install a device driver which reads a file containing instructions 

for a device. The driver reads the file and writes (or downloads) these instructions 
4: into the device's memory. However, this type of device driver permits only limited 
O addressing capability for memory and input/output operations. In addition, it does 
15M : not allow execution of the system's processor instructions in physical memory 
o space. 

p Accordingly, there is a need in the technology for a system and method for 

accessing and executing the contents of physical memory from a virtual memory 
subsystem, which facilitates increased addressing capability for memory and 
20 input /output operations, and which also allows execution of processor instructions 
directly from physical memory. 

Furthermore, data stored on computer systems or platforms can be updated or 
configured. In certain cases, the data is extremely sensitive. A good example of 
configurable sensitive data is the Basic Input and Output System (BIOS) of a 
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computer system. Typically stored in some form of non-volatile memory, the BIOS 
is machine code, usually part of an Operating System (OS), which allows the Central 
Processing Unit (CPU) to perform tasks such as initialization, diagnostics, loading 
the operating system kernel from mass storage, and routine input/output ("I/O") 
functions. Upon power up, the CPU will "boot up" by fetching the instruction code 
residing in the BIOS. Without any security protection, the BIOS is vulnerable to 
attacks through capturing and replaying of service requests to invoke functions 
provided by the BIOS. These attacks may corrupt the BIOS and disable the computer 
system. 

Accordingly, there is also need to provide a system and method to verify the 
integrity of service requests to access or modify data in the BIOS and to enforce 
proper authorization limits of those remote request messages. 
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STTMMARV OF THE INVENTION 

The present invention provides a system and method for securely utilizing 
Basic Input and Output System (BIOS) services. 

In accordance with one aspect of the current invention, the system comprises 
5 a memory for storing instruction sequences by which the processor-based system is 
processed, where the memory includes a physical memory and a virtual memory. 
The system also comprises a processor for executing the stored instruction 
S sequences. The stored instruction sequences include process acts to cause the 
SJ processor to: map a plurality of predetermined instruction sequences from the 
lQp physical memory to the virtual memory, determine an offset to one of the plurality 
G of predetermined instruction sequences in the virtual memory, receive an 
Si instruction to execute the one of the plurality of predetermined instruction 
U sequences, transfer control to the one of the plurality of predetermined instruction 
n sequences, and process the one of the plurality of predetermined instruction 
15 sequences from the virtual memory. 

Another aspect of the system includes an access driver to generate a service 
request to utilize BIOS services such that the service request contains a service 
request signature created using a private key in a cryptographic key pair. The systen 
also includes an interface to verify the service request signature using a public key i 
20 the cryptographic key pair to ensure integrity of the service request. 
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BRTEF DESCRIPTION OF THE DRAWINGS 



Figure 1 is a system block diagram of one embodiment of an information 
distribution system in which the and method of the invention is used. 

Figure 2 illustrates an exemplary processor system or user computer system 
5 which implements embodiments of the present invention. 

Figure 3 illustrates a diagram of one embodiment of the computer system of 
Figure 2, in which the system and method of invention is used. 

Figure 4 is an overall functional block diagram illustrating the architecture of 
an operating system which utilizes the system and method of the present invention. 

lOfi Figure 5 is a block diagram illustrating the access driver 46 initialization 

process as provided in accordance with the principles of the present invention. 

in Figure 6A is a flowchart illustrating one embodiment of the initialization 

s process of the present invention. 

H Figure 6B is a flowchart illustrating the details of process block 610 of Figure 

1#* 6A. 

Figure 6C is a flowchart illustrating the details of process block 630 of Figure 

6A. 

Figure 7 A is a flowchart illustrating the execution process of the present 
invention. 
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Figure 7B is a flowchart illustrating the details of process block 640 of Figure 

7A/ 

Figure 8 is another overall functional block diagram illustrating the 
architecture of an operating system which utilizes the system and method of the 
present invention. 

Figure 9 shows an illustrative sequence of interactive sequence between two 
system components in accordance with one embodiment of the current invention. 

Figure 10 outlines the generation of a session request in accordance with one 
embodiment of the current invention. 

Figure 11 shows an authority certificate in accordance with one embodiment 
of the current invention. 

Figure 12 shows a session request in accordance with one embodiment of the 
current invention. 

Figure 13 shows a service request in accordance with one embodiment of the 
current invention. 

Figure 14 outlines the acts required to establish a work session in accordance 
with one embodiment of the current invention. 

Figure 15 outlines the generation of a service request in accordance with one 
embodiment of the current invention. 
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Figure 16 shows the acts required in processing of a service request in 
accordance with one embodiment of the current invention. 

Figure 17 shows the acts involved in ending the current work session in 
accordance with one embodiment of the current invention. 

Figure 18 shows the process of generating an authority certificate in 
accordance with one embodiment of the current invention. 
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DETAILED DESCRIPTION OF THE PREFERRED INVENTION 



Definitions 

As discussed herein, a "computer system 11 is a product including circuitry 
capable of processing data. The computer system may include, but is not limited to, 

5 general purpose computer systems (e.g., server, laptop, desktop, palmtop, personal 
electronic devices, etc.)/ personal computers (PCs), hard copy equipment (e.g., 
printer, plotter, fax machine, etc.), banking equipment (e.g., an automated teller 
machine), and the like. An infomediary is a web site that provides information on 

O behalf of producers of goods and services, supplying relevant information to 
Id" businesses about products and /or services offered by suppliers and other businesses. 

=D Content refers to application programs, driver programs, utility programs, the 

Lr payload, etc., and combinations thereof, as well as graphics, informational material 

J (such as articles, stock quotes, etc.) and the like, either singly or in any combination. 

k In addition, a "communication link' 1 refers to the medium or channel of 
lir; communication. The communication link may include, but is not limited to, a 

zi telephone line, a modem connection, an Internet connection, an Integrated Services 
Digital Network ("ISDN") connection, an Asynchronous Transfer Mode (ATM) 
connection, a frame relay connection, an Ethernet connection, a coaxial connection, 
a fiber optic connection, satellite connections (e.g. Digital Satellite Services, etc.), 
20 wireless connections, radio frequency (RF) links, electromagnetic links, two way 
paging connections, etc., and combinations thereof. Power On Self Test (POST) 
refers to the instructions that are executed to configure and test the system hardware 
prior to loading an OS. 
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System Overview 

A description of an exemplary system, which incorporates embodiments of 
the present invention, is hereinafter described. 

Figure 1 shows a system block diagram of one embodiment of an information 
5 distribution system 10 in which the system and method of the invention is used. 
The system 10 relates to providing an infomediary. It involves the construction and 
maintenance of a secure and private repository of Internet user and system profiles, 
collected primarily from warranty service registrations, Internet service 
registrations, system profiles, and user preferences. Initially, this information is 
ICh used to register the user with the manufacturers of purchased hardware and 
m software products, and with the providers of on-line or other services. Over time, 
*3 the user data is used to create a user profile and notify users of relevant software 
£ updates and upgrades, to encourage on-line purchases of related products, and to 
O enable one-to-one customized marketing and other services. 

153 In one embodiment, two software modules are used to implement various 

LJ embodiments of the invention. One is resident on a user's system, and is used to 
Q access a predetermined web site. For example, in one embodiment, the operating 
system and Basic Input and Output System (BIOS) are pre-installed on a computer 
system, and when the computer system is subsequently first powered up, an 

20 application, referred to for discussion purposes as the first software module (in one 
embodiment, the first software module is the initial start-up application (ISUA), 
which will be described in the following sections), will allow the launching of one 
or more executable programs in the preboot environment. In one embodiment, the 
first software module facilitates the launching of one or more executable programs 

25 prior to the loading, booting, execution and /or running of the OS. In one 
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embodiment, the user is encouraged to select the use of such a program (i.e., the use 
of the first software module), and in alternative embodiments, the program is 
automatically launched. The program(s) contained in the first software module 
enables tools and utilities to run at an appropriate time, and with proper user 
5 authorization, also allow the user to download a second software module that 
includes drivers, applications and additional payloads through the Internet 
connection on the PC. The programs may also provide for remote management of 
the system if the OS fails to launch successfully. 

Once the second software module has been delivered, it may become memory 
10__ resident, and may disable the transferred copy of the first software module. The 
y=I original copy of the first software module still residing in the system's non-volatile - 

memory remains idle until the second software module fails to function, becomes 
ji corrupted or is deleted, upon which a copy of the original first software module is 
O again transferred as described above. The second software module may include an 
lsL application that connects the user to a specific server on the Internet and directs the 
?i user to a predetermined web site to seek authorization to down load further 
W subscription material. The second software module may also include content that is 
O the same or similar to the content of the first software module. 

In one embodiment, the system may also include an initial payload that is 
20 stored in Read Only Memory BIOS (ROM BIOS). In one embodiment, the initial 
payload is part of the first software module (e.g., the ISUA). In an alternative 
embodiment, the initial payload is stored as a module in ROM BIOS, separate from 
the first software module. In one embodiment, the initial payload is launched from 
ROM BIOS and displayed on the screen after the Power On Self Test (POST) but prior 
25 to the booting, loading and /or execution of the OS. This may occur at a 

predetermined time, such as when the system is being manufactured, assembled 
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and tested, or when the end user first activates the system. In an alternate 
embodiment, this initial payload is copied to a predetermined location (such as the 
system's hard disk) at a predetermined time, such as when the system is being 
manufactured, assembled and tested, or when the end user first activates the system. 
5 Once copied, the payload executes after POST but prior to operation of the OS, and 
may display graphics, advertisements, animation, Joint Photographic Experts Group 
(JPEG) /Moving Picture Experts Group (MPEG) formatted material on the screen. 
When additional programs and /or payloads are delivered (via the Internet or other 
outside connection), the display screen may be used to provide customized screens 
10 in the form of messages or graphics prior to and during booting of the OS. In 
addition, executable programs delivered in the first software module, as well as 
subsequent programs (such as the second software module) downloaded from the 
web site, may be used to survey the PC to determine various types of devices, 
ij": drivers, and applications installed. In one embodiment, as described in co-pending 

li> U.S. Patent Application serial number , entitled "Method and Apparatus for 

}• Automatically Installing And Configuring Software on a Computer", filed June 18, 
iL 1999, assigned to Phoenix Technologies Ltd., the contents of which are incorporated 
: herein by reference, the first software module is used to identify and to 
O automatically create shortcuts and /or bookmarks for the user. The programs 
2@J downloaded from the website may include software that collects and maintains a 
o user profile based on the user's preferences. Such information may be provided to 
' the infomediary, which subsequently forwards portions of the information and /or 
compiled data based on the information to suppliers and other businesses to obtain 
updates or revisions of information provided by the suppliers and other businesses. 

25 Referring to Figure 1, the information distribution system 10 comprises a 

service center 20 that is connected over one or more communications links 30 r 30 N 
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to one or more user computer systems 40^0^ ("40"). The service center 20 includes 
one or more servers 22, one or more databases 24, and one or more computers 26 x - 
26 M . The one or more computers 26 r 26 M are capable of simultaneous access by a 
plurality of the user computer systems 4Q r 40 N . If a plurality of computers are used, 
then the computers 26 T -26 M may be connected by a local area network (LAN) or any 
other similar connection technology. However, it is also possible for the service 
center 20 to have other configurations. For example, a smaller number of larger 
computers (i.e. a few mainframe, mini, etc, computers) with a number of internal 
programs or processes running on the larger computers capable of establishing 
communications links to the user computers. 

The service center 20 may also be connected to a remote network 50 (e.g., the 
Internet) or a remote site (e.g., a satellite, which is not shown in Figure 1). The 
remote network 50 or remote site allows the service center 20 to provide a wider 
variety of computer software, content, etc. that could be stored at the service center 
20. The one or more databases 24 connected to the service center computer(s), e.g., 
computer 26 v are used to store database entries consisting of computer software 
available on the computer(s) 26. In one embodiment, each user computer 40j-40 N 
has its own secure database (not shown), that is not accessible by any other 
computer. The communication links 30 r 30 N allow the one or more user computer 
systems 40^40,^ to simultaneously connect to the computer(s) 26 r 26 M . The 
connections are managed by the server 22. 

After a user computer system 40 establishes two-way communications with 
the information service computer 26, the content is sent to the user computer 
system 40 in a manner hereinafter described. The downloaded content includes an 
application that surveys the user and /or the user computer system's hardware 
and /or software to develop a user profile as well as a profile of the user's system. 
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The information gathered from the user and /or user's computer system is 
subsequently provided to the service center 20, which provides additional content to 
the user computer 40 based on the user and system profile. The database entries 
from the database connected to the service computer 26 contain information about 

5 computer software, hardware, and third party services and products that are 

available to a user. Based on the user and/or system profile, the content is further 
sent to the user computer for display. The content may also include a summary of 
information such as the availability of patches and fixes for existing computer 
software, new versions of existing computer software, brand new computer 
10 software, new help files, etc. The content may further include information 

7^ regarding availability of hardware and third party products and services that is of 

^ interest to the user. The user is then able to make one or more choices from the 
summary of available products and services, and request that the products be 

J: J; transferred from the service computer 26 to the user computer. Alternatively, the 
15 user may purchase the desired product or service from the summary of available 

P products and services. 

r j Figure 2 illustrates an exemplary computer system 100 that implements 

embodiments of the present invention. The computer system 100 illustrates one 
embodiment of user computer systems 40 r 40 N and/or computers 26 r 26 M (Figure 1), 
20 although other embodiments may be readily used. 

Referring to Figure 2, the computer system 100 comprises a processor or a 
central processing unit (CPU) 104. The illustrated CPU 104 includes an Arithmetic 
Logic Unit (ALU) for performing computations, a collection of registers for 
temporary storage of data and instructions, and a control unit for controlling 
25 operation for the system 100. In one embodiment, the CPU 104 includes any one of 
the x86, Pentium™, Pentium II™, and Pentium Pro™ microprocessors- as marketed 
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by Intel™ Corporation, the K-6 microprocessor as marketed by AMD™, or the 
6x86MX microprocessor as marketed by Cyrix™ Corp. Further examples include the 
Alpha™ processor as marketed by Digital Equipment Corporation™, the 680X0 
processor as marketed by Motorola™; or the Power PC™ processor as marketed by 
5 IBM™. In addition, any of a variety of other processors, including those from Sun 
Microsystems, MIPS, IBM, Motorola, NEC, Cyrix, AMD, Nexgen and others may be 
used for implementing CPU 104. The CPU 104 is not limited to microprocessor but 
may take on other forms such as microcontrollers, digital signal processors, reduced 
instruction set computers (RISC), application specific integrated circuits, and the 
10 like. Although shown with one CPU 104, computer system 100 may alternatively 
include multiple processing units. 

J The CPU 104 is coupled to a bus controller 112 by way of a CPU bus 108. The 

;;! bus controller 112 includes a memory controller 116 integrated therein, though the 
£ : memory controller 116 may be external to the bus controller 112. The memory 
15h controller 116 provides an interface for access by the CPU 104 or other devices to 
D system memory 124 via memory bus 120. In one embodiment, the system memory 
124 includes synchronous dynamic random access memory (SDRAM). System 
memory 124 may optionally include any additional or alternative high speed 
memory device or memory circuitry. The bus controller 112 is coupled to a system 
20 bus 128 that may be a peripheral component interconnect (PCI) bus, Industry 

Standard Architecture (ISA) bus, etc. Coupled to the system bus 128 are a graphics 
controller, a graphics engine or a video controller 132, a mass storage device 152, a 
communication interface device 156, one or more input/output (I/O) devices 168 r 
168 N , and an expansion bus controller 172. The video controller 132 is coupled to a 
25 video memory 136 (e.g., 8 Megabytes) and video BIOS 140, all of which may be 
integrated onto a single card or device, as designated by numeral 144. The video 
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memory 136 is used to contain display data for displaying information on the 
display screen 148, and the video BIOS 140 includes code and video services for 
controlling the video controller 132. In another embodiment, the video controller 
132 is coupled to the CPU 104 through an Advanced Graphics Port (AGP) bus. 

5 The mass storage device 152 includes (but is not limited to) a hard disk, floppy 

disk, CD-ROM, DVD-ROM, tape, high density floppy, high capacity removable 
media, low capacity removable media, solid state memory device, etc., and 
combinations thereof. The mass storage device 152 may include any other mass 
storage medium. The communication interface device 156 includes a network card, 
10 a modem interface, etc. for accessing network 164 via communications link 160. The 
3 I/O devices 168 r 168 N include a keyboard, mouse, audio/sound card, printer, and the 

like. The I/O devices 168 r 168 N may be a disk drive, such as a compact disk drive, a 
1 digital disk drive, a tape drive, a zip drive, a jazz drive, a digital video disk (DVD) 
K drive, a solid state memory device, a magneto-optical disk drive, a high density 
If floppy drive, a high capacity removable media drive, a low capacity media device, 
E and /or any combination thereof. The expansion bus controller 172 is coupled to 
W nonvolatile memory 175 which includes system firmware 176. The system 
O firmware 176 includes system BIOS 82, which is for controlling, among other things, 
hardware devices in the computer system 100. The system firmware 176 also 
20 includes ROM 180 and flash (or EEPROM) 184. The expansion bus controller 172 is 
also coupled to expansion memory 188 having RAM, ROM, and/or flash memory 
(not shown). The system 100 may additionally include a memory module 190 that is 
coupled to the bus controller 112. In one embodiment, the memory module 190 
comprises a ROM 192 and flash (or EEPROM) 194. 

25 As is familiar to those skilled in the art, the computer system 100 further 

includes an operating system (OS) and at least one application program, which in 
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one embodiment, are loaded into system memory 124 from mass storage device 152 
and launched after POST. The OS may include any type of OS including, but not 
limited or restricted to, DOS, Windows™ (e.g., Windows 95™, Windows 98™, 
Windows NT™), Unix, Linux, OS/2, OS/9, Xenix, etc. The operating system is a set 
of one or more programs which control the computer system's operation and the 
allocation of resources. The application program is a set of one or more software 
programs that performs a task desired by the user. 

In accordance with the practices of persons skilled in the art of computer 

programming, the present invention is described below with reference to symbolic 

representations of operations that are performed by computer system 100, unless 

indicated otherwise. Such operations are sometimes referred to as being computer- 
s' 

executed. It will be appreciated that operations that are symbolically represented 
include the manipulation by CPU 104 of electrical signals representing data bits and 
the maintenance of data bits at memory locations in system memory 124, as well as 
other processing of signals. The memory locations where data bits are maintained 
are physical locations that have particular electrical, magnetic, optical, or organic 
properties corresponding to the data bits. 

When implemented in software, the elements of the present invention are 
essentially the code segments to perform the necessary tasks. The program or code 
segments can be stored in a processor readable medium or transmitted by a 
computer data signal embodied in a carrier wave over a transmission medium or 
communication link. The "processor readable medium" may include any medium 
that can store or transfer information. Examples of the processor readable medium 
include an electronic circuit, a semiconductor memory device, a ROM, a flash 
memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a 
hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data 
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signal may include any signal that can propagate over a transmission medium such 
as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The 
code segments may be downloaded via computer networks such as the Internet, 
Intranet, etc. 

5 Figure 3 illustrates a logical diagram of computer system 100. Referring to 

Figures 2 and 3, the system firmware 176 includes software modules and data that 
are loaded into system memory 124 during POST and subsequently executed by the 
processor 104. In one embodiment, the system firmware 176 includes a system BIOS 
module 82 having system BIOS handlers, hardware routines, etc., a ROM 
lft: application program interface (RAPI) module 84, an initial start-up application 
2£ (ISUA) module 86, an initial payload 88a, cryptographic keys 90, a cryptographic 
"'V engine 92, and a display engine 94. The aforementioned modules and portions of 
f\: system firmware 176 may be contained in ROM 180 and/or flash 184. Alternatively, 
the aforementioned modules and portions of system firmware 176 may be contained 
IB in ROM 190 and/or flash 194. The RAPI 84, ISUA 86, and initial payload 88a may 
O each be separately developed and stored in the system firmware 176 prior to initial 
o use of the computer system 100. In one embodiment, the RAPI 84, ISUA 86, and 
initial payload 88a each includes proprietary software developed by Phoenix 
Technologies, Ltd. 

20 RAPI 84 generally provides a secured interface between ROM application 

' programs and system BIOS 82. One embodiment of RAPI 84 is described below in 
Figures 8 through 18 and the accompanying text. One embodiment of ISUA 86 is 

described in co-pending U.S. Patent Application serial number entitled 

"Method and Apparatus for Automatically Installing and Configuring Software on a 

25 Computer/' filed on June 18, 1999, assigned to Phoenix Technologies, Ltd., and 
which is incorporated herein by reference. 
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Accessing and Executing Contents of Physical Memory From Virtual Memory 



One aspect of the present invention is described with reference to an 
operating system installed on the processing system 100, shown in Figure 2. Figure 4 
is an overall functional block diagram illustrating the architecture of a processing 
5 system utilizing the system and method of the present invention. The processing 
system 100 comprises an operating system 2230 which supports application 
programs 232 and services 2234, Basic Input/Output System ("BIOS") 236 and system 
hardware 238. The BIOS 236 is a collection of drivers, or software interfaces for 
hardware devices such as the console (keyboard and display), a generic printer, the 
T# auxiliary device (serial port), the computer's clock and the boot disk device. The 
% j BIOS 236 is typically embedded in programmable, read only memory (ROM). Often, 
4- the BIOS functions themselves are actually copied from ROM into physical 
P memory, taking advantage of the faster access times of physical memory. This is 
^, known as "shadowing" the BIOS 236 because two copies of BIOS 236 results: one in 
IS ROM (which will no longer be used) and the other in physical mempry. The 
S portion of physical memory which stores the BIOS 236 is known as the BIOS shadow 
space. An operating system such as Windows NT makes no use of the BIOS 236 
after the operating system has been booted and is running. The kernel level drivers 
in the Windows NT operating system interface directly with the system hardware. 
20 The present invention facilitates the use of the BIOS 236 as an interface between 
system hardware 238 and an operating system 232. 

The operating system 230 includes a class driver 240 which interfaces with the 
application programs 232 and services 2234, and an I/O Manager 242. The I/O 
Manager 242 converts I/O requests from the application programs 232 and services 
25 234 (made via the class driver 240) into properly sequenced calls to various driver 
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routines located in the kernel 244. In particular, when the I/O Manager 242 receives 
an I/O request, it uses the function codes of the request to call one of several 
dispatch routines in a driver located in the kernel 244. The kernel 244 provides 
hardware-independent functions, called system functions, that are accessed by 
5 means of a software interrupt. The functions provided by the kernel 244 include file 
and directory management, memory management, character device input/ output 
and time and date support, among others. In one embodiment, the operating system 
is the Windows NT operating system. In alternate embodiments, the operating 
system 230 includes the Solaris or the ADC operating systems or other operating 
10 systems based on demand-paged virtual memory subsystems. 

€l The present invention provides an access driver 246, located within the 

H kernel 244, which is responsible for accessing BIOS data located in the BIOS 236 or 
1 for accessing system hardware 238 data via the BIOS 236. The access driver 246 is 
O also responsible for accessing the location of a BIOS function address, as well as 

1%±, executing the associated BIOS function. In one preferred embodiment, the access 
S driver 244 comprises source code written in the C language. It is understood that 
S other assembly languages may be utilized in implementing the functions of the 
° access driver 244. The BIOS data and addresses are typically located in physical 
memory 250 and are accessed by the access driver 246 via a BIOS Interface 248. In 

20 one embodiment, the access driver 246 executes code in the BIOS shadow space, 
typically at physical addresses OxOOOEOOOO through OxOOOFFFFF. 

By way of example, if the access driver 246 needs to access BIOS functions 
located in physical memory at address 0x00000000. It makes a call to the I/O Manager 
242, requesting it to map the memory space at physical address 0x00000000 through 
25 OxOOOOOFFF to its virtual memory space. The I/O Manager 242 then returns a 
pointer to the virtual memory space of the access driver 246, for example, 
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0xfd268000. The access driver may now reference the address space at physical 
address OxOOOOOOOO by basing or referring its virtual addresses with 0xfd268000. 
Thus, to access a function located at physical address 0x2400, the virtual address used 
would be 0xfd2682400. 

5 In one preferred embodiment, a set of entry-points or functions calls are 

available to the application programs 230, services 232 or class driver 240 which 
utilize the access driver 246. The access driver 246 can be opened, closed, and can 
receive input/ output ("I/O") control codes ("IOCTLs") through these entry points. 
Table 1 illustrates the structure, entry points and applications for the access driver 
% 246. 

F! Figure 5 is a block diagram illustrating the access driver 246 initialization 

® process as provided in accordance with the principles of the present invention. In 
W general, when the access driver 246 is first loaded, its DriverEntry function (see Table 
= 1) is executed. Although a number of other initializations occur in this function 
153 (such as the allocation of various resources or objects for normal operation of the 
LJ access driver 246), two particularly essential initializations occur: (a) the BIOS 
O shadow area 260 (which includes a BIOS Service Directory 62) located in physical 
memory 250 and (b) the BIOS data area 264, also located in physical memory 250, are 
both mapped into the virtual memory (shown in Figure 5 as the BIOS shadow area 
20 270 (which includes the BIOS Service Directory 272 and the BIOS data area 74) of the 
access driver 246. As a result, application programs 232 or services 2234 may, 
through the class driver 240, access or execute BIOS functions using virtual 
addressing. It should be noted that execution of the BIOS function must occur from 
the access driver 246 because the physical address space of the BIOS 236 is mapped 
25 only to the access driver 246. In addition, the access driver 246 may be utilized 

through the implementation of a 32-bit BIOS Power Management Service Interface 
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as described in detail in Appendix A. It is apparent to one skilled in the art that the 
BIOS Power Management Service Interface may also be implemented for 64-bit, 128- 
bit and 256-bit configurations. The access driver 246 can also operate in 64-bit, 128-bit 
and 256-bit configurations. 

5 In particular, the access driver 246, during initialization, locates the BIOS 

shadow area 260 and the BIOS data area 264 located in physical memory 250. The 
BIOS shadow area 260 and the BIOS data area 264 are mapped into the virtual 
address space of the access driver 246. Next, the access driver 246 performs a search 
for the BIOS Service Directory 272 header. Upon finding and validating the BIOS 
lflk Service Directory 272, the access driver 246 obtains the virtual address of the BIOS 

£ Service Directory 272 header, which provides the offset of the BIOS Service Directory 
272 header virtual address from the base virtual address of the BIOS shadow area 

£ 270. 

s In an alternate embodiment, the access driver, during initialization, locates 

m the BIOS shadow area 260, the BIOS data area 264 and the BIOS ROM area located in 
U physical memory 250. The BIOS shadow area 260, the BIOS data area 264 and the 
p! BIOS ROM area are mapped into the virtual address space of the access driver 246. 
Next, the access driver 246 performs a search for the BIOS Service Directory 272 
header. Upon finding and validating the BIOS Service Directory 272, the access 
20 driver 246 obtains the virtual address of the BIOS Service Directory 272 header. In 
this alternate embodiment, the availability of the BIOS ROM area in the virtual 
memory space of the access driver 246 enables the access driver 246 to read and/ or 
write data in flash ROM. As a result, the BIOS ROM can be reflashed or rewritten. 
In addition, outside application programs which interface with hardware can access 
25 the BIOS ROM area through software mechanisms such as that described in the 
PhoenixPhlash NT specification provided in Appendix B. 
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Later, calls to an execution function in the access driver 246 will utilize the 
base virtual address of the BIOS shadow area 270 and the offset to invoke a requested 
entry point in the BIOS itself- It should be .noted that an application program 232 or 
service 234 may cause execution of the BIOS function anywhere in the BIOS 1 virtual 
5 address space, and not only through the BIOS Service Directory 272. 

In one embodiment, the execution function that is called to invoke a 
requested entry point in the BIOS is the IOCTL_BIOS_EXEC function, which is 
described in Table 1. The IOCTL_BK)S_EXEC function creates a register stack in a 
buffer (which is specified by the calling application program 232 or service 234) 
10 located in main memory or DRAM. The contents of the stack are the desired 
% register values at the time the BIOS function is invoked. The access driver 246 
J; ! passes the register stack from the calling application program 232 or service 234. The 
iy :f procedure call itself is performed using a pointer to the function specified in the 
VI BIOS Service Directory 272. In one embodiment, the BIOS function called by 
15* IOCTL_BIOS_EXEC accepts a 4-byte signature as an argument and locates the BIOS 
O function associated with the signature. Values passed back to the calling application 
Q program 232 or service 234 include the base virtual address of the BIOS function, 
n and the offset from the base address of the service's entry point. 

A general discussion of the structure, entry functions and applications for 
20 access driver 246 will now be provided. 



Table 1. Access Driver 246 Functions 



Function Name 


Description 


Remarks 


DriverEntry 


Kernel calls this function at 
load time to cause the driver 
to initialize itself. 
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Access Driver CreateClose 


Kernel calls this function to 
create or close out the 
driver's functionality. 




Arrpcc F)Hvpt Unload 

rlLLCjO L/iivti uiiiuwu 


Called by Kernel for Service 
Control Manager to unload 
the driver. This function 
frees all resources established 
at load time. 




IOCTL_Locate 


Locates the BIOS 232-bit entry 
point using a string search. 
The entry point virtual 
address, the BIOS base 
virtual address and the BIOS 
data area virtual address are 
returned to the caller. 
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Table 1. Access Driver 246 Functions 
(continued) 



Function Name 


Description 


Remarks 




I^pjiHq Hafa frr\m PifrhpT tnp 

XXCCllA^ via. LA XlVJXXL CiULCl tilt 

BIOS ROM, shadow or BIOS 
data area and returns it to the 
ncp/c huffpr 




IOCTL_BIOS_Write 


Writes data to either the 
BIOS ROM, shadow or BIOS 
data area from the user's 
buffer. 




1 L — DlVJZ5_IiXeC 


1 ctboct? CAcCUtlUIl lU d DXKJO 

entry point via the 232-bit 
entry point 




IOCTL_RTC_Read 


Reads the real-time clock 
Qaie ana time ana returns 
these to the calling function. 


Format of 

rctUrilfcrU Udld Will 

match 

SYSTEMTIME 
template. 


IOCTL_Version 


Returns the version number 
or tne driver to tne caiier 


Includes a bitmap 
or currently 
implemented 
functions 


Access Driver DriverReg 


ivegisters tne caning aevice 
by its object name and 

CCtllVJillV-Cli lLCtlilC' 


1 lie Hot UI 

registered devices 

will bp uspd to 

V V 1X1 L/C d.Ov_ lU 

resume and 
suspend. 


Access Driver DriverReg 


Deregisters the calling 
device. 


The device must 
have registered 
already. 


IOCTL_PM_Suspend 


The function sends Suspend 
IRP's to all registered devices. 




IOCTL_PM_Resume 


The function sends Resume 
IRP's to all registered devices. 
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A. Detailed description of the Access Driver 246 functions 
1. The "DriverF.ntry" function 

This entry point causes the driver to initialize its variables, map in the BIOS 
shadow and data areas, and to allocate resources for its normal operation. As each 
resource or object is allocated, it is tabulated into the variable 'phResAndFlags'; this 
allows a single function ('freeResources') to free up resources used by the driver, no 
matter the reason for the driver being unloaded. The resources allocated or 
connected to are as follows: 

a. Create the Device Object - establishes a device object and name 
with the system. 

b. Initialize Error Logging - creates a link to the Event Log services. 

c. Set up the major function entry points. 

d. Create a Symbolic link - for use by Service or Application layers. 

e. Map in the BIOS shadow - makes this memory space accessible 
in virtual memory to the driver. 

f. Map in the BIOS ROM - makes the ROM area accessible in 
virtual memory address space. 

g. Map in the BIOS Data - makes this memory space accessible in 
virtual memory to the driver. 

h. Locate the BIOS 232-bit entry point for use by this driver. 
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In one embodiment, the device object name is 'Laptop', which is required in 
order to service the nexus functions required by the Microsoft OEM Adaptation Kit 
(OAK). The corresponding symbolic link name is ThoenixAD'. 

2. AccessDriverCreateClose 

This function is used to inform the driver 246 when an application program 
232 or service 234 makes a request to the system for a device handle, or when it 
closes a handle already obtained. The Access Driver 246 responds to this dispatch 
entry point by completing the request successfully, but changing no other state 
variable of the driver 246. 

3. AccessDriverUnload 

This dispatch entry point is called by the kernel on behalf of the Service 
Control Manager (SCM) or other application when it is necessary to remove the 
driver from the system (device close from (SCM)). The result of this function call is 
that all resources tabulated in 'phResAndFlags' are freed to the system and the 
request is completed successfully- 
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4. AccessDriverReg 



The Access Driver 246 driver has the function of performing "nexus 
processing" for the power management model provided as part of the OEM 
Adaptation Kit (OAK). This function is integral to the emulation of power 

5 management for OEM and standard devices having knowledge of and a 

requirement to use the OAK control methods. The AccessDriverReg function 
registers devices into a linked list. It also selectively "deregisters" devices on 
request* Typically OAK compliant device drivers will make the call for registration 
when their DriverEntry function is executed (when they are first loaded). And as 
lg j part of the DriverUnload function, each registered device must make the call to 

fl: remove itself from Access Driver 246's linked list of devices needing power 

, management services. 

L 5. IOCTL Functions 

It Every interface between the service or application layer and the BIOS is 

ll£ handled by an IOCTL function in the Access Driver 246 driver. Each IOCTL transfer 
C is performed in Buffered Mode, so that the input data to the driver and its output 
data are transferred through a common system buffer. The pointer to this buffer 
space is given in the Input/Output (I/O) Request Packet as 

Irp>AssociatedIrp.SystemBufferi Upon being given control, the IOCTL (within the 
20 driver) will get the system buffer address and use its contents to perform the request. 
The results of the IOCTL function's execution will be placed in the same system 
buffer as was used for input. 

Each IOCTL that is implemented in the Access Driver 246 driver has a unique 
data format for IOCTL input data and for its output data. As the functions are 

002603.P002X -27- 
KGN/SND/phs 



described below, their data buffer formats and descriptions of each field are given. 
Buffer offsets are given in bytes. The minimum buffer size given for each function 
is a recommended malloc() size to use for the application program's user buffers. 
System buffer sizes will automatically be derived from the user buffers. 

6. IOCTL Locate 

The IOCTL_Locate function is the first dispatch entry point to be called by the 
application program 232 or service 234 after the driver 246 initializes. The function 
returns the addresses of the BIOS232 Service Interface, the base address of the BIOS 
shadow area, and the base address of the BIOS Data Area, in flat-model virtual 
address format (232 bit addresses). Note that the BIOS232 Service Interface is the 
single entry point for all BIOS functions executed from the driver level or kernel 
threads (see Appendix A). The BIOS232 Service Interface is the single entry point for 
all BIOS functions executed from the driver level or kernel threads (see Appendix 
A). These address spaces are guaranteed to be accessible to this driver (only) during 
the time the Access Driver 246 driver is loaded. 

Input data: None, do not rely on buffer contents 

Output data: Offset 0: PUCHAR - BIOS Service Directory Offset into 

Shadow. 

Offset 4: PUCHAR - BIOS Shadow Area Base Virtual 

Address. 

Offset 8: PUCHAR - BIOS Data Area Base Virtual 

Address. 
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Offset 8: PUCHAR - BIOS Data Area Base Virtual 

Address. 

Offset 12: PUCHAR - BIOS ROM Area Base Virtual 

Address. 

Min. Buffer Size: 16 bytes 
7. IOCTL BIOS Read 

The IOCTL BIOS_Read function is a general purpose reader of either the BIOS 
ROM, shadow area, or the data area. 

Input Data: Offset 0: ULONG - Mode Flags 

Bit 0: 1 = shadow area, 0 = data area. 

Bit 2: 1 = ROM area (overrides Bit 0) 

Offset 4: PUCHAR - Offset into the BIOS area to start the 

read 

Offset 8: ULONG - Length of the read in bytes; 

Output Data: Offset 0: ULONG- Length of the actual read 

Offset 4: UCHAR array - the actual data read 

Min. Buffer Size: 16 bytes 

Note: If a 'short read' occurs because the offset into the BIOS area specified an 
overlap with the end of the mapped BIOS memory, no error is returned. Instead the 
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'actual data read' field accurately indicates how much of the data is valid in the 
system buffer. 



8. IOCTL BIOS Write 

The IOCTL_BIOS_Write function is a general purpose writer of either the 
5 BIOS ROM, shadow, or the data area. 

Input Data: Offset 0: ULONG - 

Bit 0: 1 = 

Bit 2: 1 = 

ri Offset 4: PUCHAR- 

101 

j£; Offset 8: ULONG - 

y Output Data: Offset 0: ULONG - 

r Offset 4: UCHAR array - the actual data read 

15 Min. Buffer Size: 16 bytes 

Note: Short writes are not permitted due to the possibility of data corruption. 

9. IOCTL BIOS Exec 

The IOCTL_BIOS„Exec function is used to execute a BIOS function through 
the BIOS232 Service Interface. An activation record is passed by value in the system 
20 buffer. The AR determines the Base Architecture register contents upon invocation 



Mode Flags 

shadow area, 0 = data area. 

ROM area (overrides Bit 0) 

Offset into the BIOS area to start the 
write 

Length of the write in bytes. 

Length of the actual write (zero, or 
request size) 
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of the entry point to the BIOS. Upon successful completion, the AR contains the 
Base Architecture context that would normally have been returned to the BIOS 
caller. 



Input Data: Offset 0: ULONG - Function entry point virtual address. 





Offset 4: ULONG - Flags Register 




Offset 8: ULONG - 


reserved 




Offset 12: ULONG - 


reserved 




Offset 16: ULONG - 


reserved 




Offset 20: ULONG - 


reserved 




Offset 24: ULONG - 


reserved 




Offset 28: ULONG - 


reserved 




Offset 232: ULONG 


reserved 




Offset 236: ULONG 


reserved 




Offset 240: ULONG 


reserved 




Offset 244: ULONG 


EBP Register 




Offset 48: ULONG - 


EDI Register 




Offset 52: ULONG - 


ESI Register 




Offset 56: ULONG - 


EDX Register 




Offset 260: ULONG 


ECX Register 


20 


Offset 64: ULONG - 


EBX Register 




Offset 68: ULONG - 


EAX Register 



Output Data: Contents of the system buffer are identical in structure. 

Register contents may have been influenced by the BIOS 
function requested. 
25 Min. Buffer Size: 80 bytes. 
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100. IOCTL RTC Read 

The IOCTL_RTC_Read function is used to read the contents of the RTC 
registers in the CMOS RAM. The data from this atomic read is formatted similarly 
to the SYSTEMTIME structure and returned to the user in the System Buffer. 

Input Data: None, do not rely on buffer contents 

Output Data: <uses SYSTEMTIME template as shown below> 

Offset 0: WORD current year 

Offset 2: WORD current month (January=l) 

Offset 4: WORD current day of week (Sunday = 0) 

Offset 6: WORD current day of month (calendar) 

Offset 8: WORD current hour 

Offset 100.-WORD current minute 

Offset 12:WORD current second 

Offset 14:WORD current millisecond 
Min. Buffer Size: 32 bytes. 

Note that the Year field in the RTC is 8 bits wide. The contents of the Year 
field in the RTC will be recalculated to a SYSTEMTIME. Year 16 bit field containing 
the entire value of the current year, AD. Examples: RTC=00, Year=1980; RTC=23, 
Year = 2003. Also note that Legacy RTC devices do not provide the millisecond field 
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in their register set. Because of this, the current millisecond field in the Output Data 
for this function will always be set to zero. 

11. IOCTL VERSION 

The IOCTL_Version function returns to the caller the major, an minor 
version of the Access Driver 246 driver. In addition, the functions implemented by 
this version of the driver are enumerated in a bitmap. The purpose of the bitmap is 
for services or higher level drivers to evaluate whether or not this version of the 
driver can be used for their purposes (at installation time, typically). 

Input Data: None, do not rely on buffer contents 

Output Data: Offset 0: WORD Major Version (X.) 

Offset 2: WORD Minor Version (.x) 

Offset 4: ULONG Bitmap of implemented functions (see 

below) 

Bit 31: 1 if IOCTL^Locate implemented 

Bit 230: 1 if IOCTL_BIOS_Read implemented 

Bit 29: 1 if IOCTL_BIOS_Write implemented 

Bit 28: 1 if IOCTL.BIOS.Exec implemented 

Bit 27: reserved 

Bit 26: reserved 

Bit 25: reserved 
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Bit 24: 1 if IOCTL_RTC_Read implemented 
Bit 23: reserved 

Bit 22: reserved for Phlash interlock 
Bit 21: reserved for online setup (NVRAM writes) 
Bit 20 - 0: reserved for future expansion 
Bit 230: 1 if IOCTL_BIOS_Read implemented 
Min. Buffer Size: 16 bytes 

12. TOCTL FM Suspend 

The IOCTL_PM_Suspend function causes IRP_MJ_PNP_POWER, 
IRP_MN_LT_SUSPEND IRP's to be sent to each device that has registered itself 
using the Access Driver DriverReg entry point. 

Input Data: None, do not rely on buffer contents 

Output Data: None, do not rely on buffer contents 

13. TOCTT, PM Resume 

The IOCTL_PM_Resume function causes IRP_MJ_PNP_POWER, 
I RP_MN_LT_RESUME IRP's to be sent to each device that has registered itself 
using the Access Driver DriverReg entry point. 

Input Data: None, do not rely on buffer contents 

Output Data: None, do not rely on buffer contents 
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B. Error Codes Returned by Access Driver 246 

The following table defines the error status returned when an IRP is 
unsuccessfully or only partially completed. Conditions of termination of the 
functions are given as well. This table is necessary because there is not necessarily a 
one-to-one correspondence between NTSTATUS values known by the operating 
system and those used by the Access Driver 246 device driver. In order to reverse 
translate the codes back into strings usable by an applications writer or an end -user, 
it is mandatory that only NTSTATUS error codes be used. 
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Table 2. NTSTATUS Codes returned from Access Driver 246 



NTSTATUS 


Function 


Condition at Termination 


STATUS_SUCCESS 


All 


Request succeeded 


STATUS SOME_NOT_MA 
PPED 


DriverEntry 


One or more of memory or 
I/O areas could not be 
mapped in. Driver load 
rails. 


STATUS_NOT_IMPLEMEN 
TED 


All 


Requested function is not 
implemented in this driver. 


STATUS_ACCESS_DENIED 


All IOCTL 

functions 


Device is unusable by caller 
because another service has 
exclusive access or because 
the BIOS Service Directory 
signature is not present. 


STATUS_MEDIA_CHECK 


All IOCTL 
functions 
- not 

implemented - 


Contents of BIOS ROM may 
have been changed. New 
call to IOCTL.Locate is 
required. 



C BIOS 232 bit Entry Point Specification 



In order for IOCTL_Locate to find the entry point for the BIOS, the BIOS 232- 
bit Service Directory is used. A description of the BIOS 232-bit Service Directory is 
described in Appendix C. The signature that Access Driver 246 will use when 
locating and executing BIOS functions shall be "_32_". 

If the WinntEntry (BIOS232 Service Directory) structure is not found subject 
to the conditions stated above, the Access Driver 246 driver will fail at load time, 
and DriverEntry will indicate that it was unable to initialize as per Table 2. 
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D. Real-Time Clock Hardware Access 



In order to implement the IOCTL_RTC_Read function, it is necessary to 
define the RTC's registers and methods of access. The RTC registers are located in 
the CMOS RAM's I/O address space. Only the RTC registers are shown in Table 3. 
The registers are accessed by outputting a CMOS physical memory address to port 
0x70, and then reading the subject 8 bit register at port 0x71. The CMOS physical 
memory address is set to point to OxOD after all RTC register have been read. 



Table 3. RTC Registers 



Register Name 


CMOS Address, Comments 


Year 


9 - years since 1980 


Month 


8 - 1 = January 


Date 


7 


Day of Week 


6 - zero equals Sunday 


Hour 


4 


Minute 


2 


Seconds 


0 



Figure 6A is a flowchart illustrating one embodiment of the initialization 
process of the present invention. Beginning from a start state, process 600 proceeds 
to block 610, the variables for the calling program (i.e., the I/O Manager 242) are 
initialized. Details of this initialization process 6100 are provided in Figure 6B and 
the accompanying text. Process 600 then proceeds to block 620 where it loads the 
access driver 246. Initialization of the access driver variables then occurs. During 
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the initialization process, two particularly essential initializations occur: (a) the 
BIOS shadow area 260 (which includes a BIOS Service Directory 62) located in 
physical memory 250 and (b) the BIOS data area 264, also located in physical memory 
250, are both mapped into the access driver's 246 virtual memory (shown in figure 4 
5 as the BIOS shadow area 270 (which includes the BIOS Service Directory 272) and the 
BIOS data area 274) of the access driver 246. 

Process 600 then advances to block 630, where pointer initialization occurs. 
Details of block 630 are provided in Figure 6C and the accompanying text. The 
process 600 then advances to block 640, where initialization ends. Process 600 then 
10 terminates. 

^ Figure 6B is a flowchart illustrating the details of block 610. Beginning from a 

start state, process 610 proceeds to block 612, where the calling program from the I/O 
fz. Manager 242 allocates memory for a specified memory structure in the system 
O , buffer. The process 610 then advances to process block 614, where the calling 
U§= program from the I/O Manager 242 determines the location of a number of BIOS 
p functions, their corresponding entry points, lengths and offsets. In one 
q embodiment, this is accomplished by entering the address field of the specified 
memory structure for the corresponding BIOS function with the virtual address of 
the BIOS function and by providing a 4-byte ASCII string identifying each BIOS 
20 function. Initialization of the calling program then terminates. 

Figure 6C is a flowchart illustrating the details of process block 630 of Figure 
6A. Beginning from a start state, the calling application program 232 or service 234, 
through the class driver, makes a call to IOCTL_Locate, as shown in block 632. In 
response, the access driver 246 performs a search for the BIOS Service Directory 272 
25 header, as shown in process block 634. . Upon finding and validating the BIOS 
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Service Directory 272, the access driver 246 obtains the virtual address of the BIOS 
Service Directory 272 header, which provides the offset of the BIOS Service Directory 
272 header virtual address from the base virtual address of the BIOS shadow area 
270. The process 630 then returns control to the calling application program 232 or 
5 service 234. 

Figure 7 A is a flowchart illustrating the calling execution process of the 
present invention. Beginning from a start state, the process 700 proceeds to process 
block 710, where the calling program calls a BIOS function by providing to the access 
driver 246, the address of the BIOS function it wants to begin execution at. The 
10 process 700 then proceeds to process block 720, where the access driver 246 receives a 
7; dispatch call to a BIOS function via an IOCTL command from the I/O Manager 242 
I.': (see Figure 4). The process 700 then proceeds to process block 730, where the access 
% driver 246 conducts a range check of the entry point address. In particular, the access 
:i driver 246 determines if the entry point address is within the range of addresses 
15 mapped to the BIOS shadow area, exclusive of the service directory header. If not, 
- the access driver 246 indicates that the starting virtual address is not within the 
k range of addresses mapped from the physical memory to the virtual memory. This 
may be indicated through the use of a flag. If the range check is successful, the 
process 700 proceeds to process block 740, where the access driver 246 executes the 
20 BIOS function called. The process 700 then terminates. 

Figure 7B is a flowchart illustrating the details of process block 740 of Figure 
7 A. Beginning from a start state, the process 740 proceeds to process block 742, where 
the access driver 246 creates a register stack in a system buffer previously specified by 
the program from the I/O Manager 242. The process 730 then advances to process 
25 block 744, where the access driver 246 provides a pointer to the register stack which 
holds the address of the BIOS function to be executed. The process 740 then proceeds 
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to process block 746, where the calling program from the I/O Manager 242 calls and 
executes the function whose beginning address is indicated by the pointer, using its 
physical address as mapped in virtual memory. The process 740 then terminates. 

An example of the utilization of the IOCTL_BIOS_EXEC function in the 
access driver 246 will now be provided. Initially, the application program 232 or 
service 234 makes a call to the access driver 246 using the command IOCTL.Locate. 
The data returned by the access driver 246 includes the BIOS Shadow Area Base 
Virtual Address, the BIOS Service Directory offset from the BIOS Shadow Area Base 
Virtual Address, and the BIOS Data Area Base Virtual Address. 

The following act is then utilized to determine the existence of a BIOS service, 
its entry point, length and address offset. A calling program from the I/O Manager 
242 first allocates memory for a register structure, such as IOC_EXECl and then fills 
in the biosFunction field of the structure with the virtual address given by the 
IOCTL_Locate function. The other register values are filled in as follows: a 4-byte 
ASCII string identifying the BIOS service is loaded into the eax register and a zero is 
loaded into the ebx register. 

Next, the caller invokes the IOCTL_BIOS_Exec function of the access driver 
246 with the contents of the IOC_EXECl structure copied into the system buffer for 
the IOCTL call. The BIOS function is then executed. The IOCTL_BIOS_Exec 
function of the access driver 246 returns, with register values for eax, ebx, ecx and 
edx each containing responses from the service directory. The calling program of 
the I/O Manager 242 then takes the information returned from the service directory 
and creates a biosFunction entry point and a structure in the system buffer. It then 
calls the BIOS function using the IOCTL_BIOS_Exec function in the access driver 
246. Returned data are passed in the same IOC_EXECl structure. 
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Examples of the processes shown in Figures 6A, 6B, 7 A and 7B are illustrated 
in Appendices D1-D3. In particular, Appendix Dl illustrates exemplary source code 
for the application program 232, service 234 or class driver 240, used in calling a 
BIOS function through the class driver 246. Appendices D2 and D3 illustrate 
5 exemplary source code for the access driver 246. Appendix D2 illustrates exemplary 
source code for executing a BIOS function in the shadow area, while Appendix D3 
illustrates exemplary source code for creating a register stack and for calling the entry 
point for executing the BIOS function. 

Through the use of the present invention, a system and method for accessing 
10 and executing the contents of physical memory from a virtual memory subsystem is 
S provided. The system and method facilitates increased addressing capability for 
F n ! memory and input/output operations, and also allows execution of processor 
O instructions in physical memory space. 

ijf Secure Utilization of BIOS services 

zi Another aspect of the present invention includes a system and method for 

" securely utilizing Basic Input and Output System (BIOS) services . In the following 

detailed description, the following terms are used to described the current 

invention: 

20 • A "key" is an encoding and/or decoding parameter in accordance with 

conventional cryptographic algorithms such as Rivest, Shamir and Adleman (RSA), 
Data Encryption Algorithm (DEA) as specified in Data Encryption Standard (DES), 
and the like. 
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A "key pair" includes a "private" key and a "public" key. A "private key" is 
held by the owner of the key pair and is used to generate digital signatures. A 
"public" key is widely published and is used to verify digital signatures. A public 
key is usually published in the form of a digital "certificate". 

5 • A "digital signature" is a digital quantity that is generated using a digital 
message and a private key. A digital signature cannot be computed without 
knowing the private key. A digital signature can be verified using the digital 
n message and a public key corresponding to the private key. Successful verification 
f S confirms that the digital message is indeed the one which was signed and that the 
1QO signature was generated using the private key corresponding to the public key. 

D • A "certificate" is a digital message containing at least a public key, a private 
h key, and a digital signature created using the private key. 

5 Figure 8 is an overall functional block diagram illustrating the architecture of 

a processing system 1500 utilizing the system and method of the present invention. 

15 The processing system 1500 comprises an operating system 1505 which supports 

application programs 1510 and services 1515, Basic Input/Output System (BIOS) 1520 
and system hardware 1525. BIOS 1520 is a collection of drivers, or software interfaces 
for hardware devices such as the console (keyboard and display), a generic printer, 
the auxiliary device (serial port), the computer's clock and the boot disk device. BIOS 

20 1520 is typically embedded in non-volatile memory. 
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The operating system 1505 includes a class driver 1530 which interfaces with 
application programs 1510 and services 1515, and an I/O Manager 1535. The I/O 
Manager 1535 converts I/O requests from application programs 1510 and services 
1515 (made via class driver 1530) into properly sequenced calls to various driver 
5 routines located in the kernel 1540. In particular, when the I/O Manager 1535 

receives an I/O request, it uses the function codes of the request to call one of several 
dispatch routines in a driver located in the kernel 1540. The kernel 1540 provides 
hardware-independent functions, called system functions, that are accessed by 
£3 means of a software interrupt. The functions provided by the kernel 1540 typically 
10?: include file and directory management, memory management, character device 
*A input/output and time and date support, among others. In one embodiment, the 
H operating system 1505 a Windows operating system. In alternate embodiments, the 
M operating system 1505 includes the Solaris or the AIX operating systems or other 
O operating systems based on demand-paged virtual memory subsystems. 

lfP The present invention provides an access driver 1545, located within the 

kernel 1540, which is responsible for interfacing with the ROM Application 
Programming Interface (RAPI) 1550 to access or update data located in BIOS 1520 or 
access system hardware data via the BIOS. RAPI 1550 generally provides an interface 
for securely utilizing BIOS services or functions. A more detailed description of 

20 RAPI is provided below. 

In one preferred embodiment, the access driver 1545 comprises source code 
written in the C language. It is understood that other assembly languages may be 
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utilized in implementing the functions of access driver 1545. In one preferred 
embodiment, a set of entry-points or functions calls are available to application 
programs 1510, services 1515 or class driver 1530 which utilize access driver 1545. 
The access driver 1545 can be opened, closed, and can receive input/output ("I/O") 
5 control codes ("IOCTLs") through these entry points. 

Figure 9 shows an illustrative sequence of interactive sequence between access 
driver 1545 and RAPI 1550 in accordance with one embodiment of the current 
invention. In a present system, a work session must be established between access 
S driver 1545 and RAPI 1550 before access driver 1545 can send one or more service 
l5j requests to RAPI 1550 to utilize BIOS services. To establish a work session with 
£ RAPI 550, access driver 1545 generates a session request (block 1605) and send the 
O request to RAPI 1550 (block 1610). 

O The format of one embodiment of a session request 900 is shown in Figure 12. 

*i Each session request 900 includes a session operation code 905, a list of parameters 
15* 910, and a session signature 915. Session operation code 905 is a numerical value 
representing one type of session operation. Illustrative examples of session 
operations in one embodiment may include an operation to begin or establish a 
session and an operation to end or terminate the session. Each type of session 
operation may require a list of one or more parameters 910. In one embodiment, 
20 the list of parameters 910 may be a pointer to a memory location where the 

parameters reside. Each session request 900 also includes a session request signature 
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915 to prevent a foreign code segment, such as a computer virus, to capture and 
replay the request and corrupt the BIOS. 

Figure 10 outlines the generation of a session request. In blocks 1705 and 1710, 
the session operation code representing a desired session operation and the list of 
5 parameters required for that desired session operation is inserted in the session 

request. Blocks 1715, 1720, and 1725 show the creation of a session request signature. 
In the art of cryptography, the act of creation of a digital signature for a message is 
known as "signing" the message. It should be noted that algorithms to sign a 
E message or to create digital signatures for a message are known in the art. It should 
lcfc! be further noted that existing algorithms for creating digital signatures generally 
]= include computing a hash value of the message to be signed and encrypting the 
O hash value using a private key, as shown in blocks 1715, 1720, and 1725. 

O It is contemplated that the Digital Signature Algorithm ("DSA") proposed by 

y the National Institute of Standards and Technology may be used. It is also 
15° contemplated that the Rivest, Shamir, and Adleman ("RSA") algorithm may be 

used. It should be noted, however, that other algorithms for generating digital 

signatures may also be employed in the present invention. 

As shown in block 1715 of Figure 10, a session message is formed such that it 
contains the session operation code and the list of parameters. In block 1720, a hash 
20 value for the session message is computed. It should be noted that algorithms to 
compute hash values are well known in the art. Those skilled in the art will 
recognize that a hash function suitable for use in embodiments of the present 
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invention is one that can compute one-way and collision-free hash values. In block 
1725, a session request signature is generated by encrypting the computed hash value 
for the session message using a private key stored in a current authority certificate. 

An authority certificate generally contains sufficient information to enable 
5 system components, such as access driver 1545 and RAPI 1550 (shown in Figure 9), 
to generate secured session or service requests and to verify the integrity of those 
requests. Figure 11 shows the format of an authority certificate 800 in accordance 
with one embodiment of the current invention. The exemplary authority certificate 
5 includes at least the following fields: a public key 805, a private key 810, and a 
lfti certificate signature 815. As described later, information stored in the authority 
]| certificate is used to enforce security limits of session and service requests. 

7 Returning to block 1615 in Figure 9, RAPI 1550 establishes a session as 

£ specified in the session request sent by access driver 1545 in block 1610. The acts 
W required to establish a session are outlined in Figure 14. In block 1105, a message is 
lB J constructed from the session operation code and list of parameters available in a 
session request received from the access driver. A hash value for the constructed 
message is computed (block 1110). The session request signature is extracted from 
the session request and decrypted using the public key included in RAPI's copy of 
the current authority certificate (block 1115). As shown later, RAPI is responsible for 
20 generating and supplying authority certificates to the access driver. RAPI, however, 
also maintains a copy of the most current authority certificates for its own use. In 
block 1120, the decrypted session signature is compared to the computed hash value 
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for the constructed message. If the computed hash value equals the decrypted 
session request signature, RAPI proceeds to start a session (block 1125). 

Returning to Figure 9, after it establishes a session, RAPI 1550 generates a new 
authority certificate (block 1620). As stated above, RAPI 1550 maintains a copy of the 
5 new authority certificate for its own use. RAPI 1550 replaces the existing authority 
certificate with the new certificate. After the replacement, the new certificate 
becomes the most current certificate. 

Figure 18 shows the process of generating an authority certificate. To generate 
S an authority certificate, a new key pair is obtained from a provided cryptographic 
lSl engine (block 2505). As defined above, a new key pair includes a public key and 
=P private key. The new keys are inserted in the new authority certificate (blocks 2510 
O and 2515). A certificate message is formed such that it includes both the new public 
tj and private keys (block 2520). A' hash value for the certificate message is computed 
h! (block 2525). A certificate signature is generated using the hash value for the 
l|5 certificate message and the new private key (block 2530). The certificate signature is 
then inserted into the new authority certificate (block (2535). 

Returning to Figure 9, RAPI 1550 sends the new authority certificate back to 
the access driver 1545 (block 1625). Upon receiving the new authority certificate, 
access driver 1545 updates the current authority certificate with information in the 
20 new certificate (block 1630). Accordingly, the information in the new authority 

certificate will be used to generate subsequent service requests. In block 1635, access 
driver 1545 generates a service request to invoke a function provided by RAPI 1550. 
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Figure 13 shows the format of a service request 1000 in accordance with one 
embodiment of the current invention. Each service request 1000 includes a service 
operation code 1005, a list of parameters 1010, and a service request signature 1015. 
Service operation code 1005 is a numerical value representing one type of service 

5 operation. Illustrative examples of service operations in one embodiment may 
include operations to read or write data stored in non-volatile memory. Each type 
of service operation may require one or more parameters that are included in the 
list of parameters. In one embodiment, the list of parameters may be a pointer to a 
memory location where a bundle of parameters reside. Each service request 1000 
1(H further includes a service request signature 1015 to prevent a foreign code segment, 

h fl such as a computer virus, to capture and replay the service request to disable or 

in cause havoc to the system. 

M Figure 15 outlines the generation of a service request in accordance with one 

O embodiment of the current invention. In blocks 1205 and 1210, the service 
l5f operation code representing a desired service operation to be performed and the list 
of parameters required for that desired operation are inserted in the service request. 
Blocks 1215, 1220, and 1225 show the creation of a service request signature. Once 
created, the service request signature is inserted in the service request (block 1230). 

Returning to Figure 9, access driver 1545 sends the service request generated 
20 in block 1635 to RAPI 1550 (block 1640). Upon receiving the service request, RAPI 
1550 processes the request (block 1645). Figure 16 shows the acts required in 
processing of a service request in accordance with one embodiment of the current 
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invention. In block 1305, a message is constructed from the service operation code 
and list of parameters available in the service request received from access driver. A 
hash value for the constructed message is computed (block 1310). The service 
request signature is extracted from the session request and decrypted using the 
public included in RAPFs copy of the current authority certificate (block 1315). In 
block 1320, the decrypted session signature is compared to the computed hash value 
for the constructed message. If the computed hash value equals the decrypted 
session request signature, RAPI performs the service specified in the service request 
(block 1325). Otherwise, the specified service will not be performed. 

Returning to Figure 9, after it processes a service request, RAPI 1550 generates 
a new authority certificate (block 1650). As described above, Figure 15 shows the 
process of generating an authority certificate. RAPI 1550 maintains a copy of the 
new authority certificate for its own use. RAPI 1550 also sends a copy of the new 
authority certificate back to access driver 1545. 

Upon receiving the new authority certificate, access driver 1545 updates the 
current authority certificate with information in the new certificate (block 1630). 
Accordingly, the information in the new authority certificate will be used to 
generate subsequent service requests. In block 1635, access driver 1545 generates a 
session request to request RAPI 1550 to end the current session. As described above, 
Figure 10 outlines the acts involved in generating a session request. Following the 
generation of a session request, access driver 1545 sends the request to RAPI 1550. 
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Upon receipt of the session request to end or terminate the session, RAPI 1550 
ends the session (block 1680). Figure 17 shows the acts involved in ending the 
current session. In block 1405, a message is constructed from the session operation 
code and list of parameters available in a session request received from the access 
5 driver. A hash value for the constructed message is computed (block 1410). The 
session request signature is extracted from the session request and decrypted using 
the public key included in RAPI's current authority certificate (block 1415). In block 
1420, the decrypted session signature is compared to the computed hash value for 
the constructed message. If the computed hash value equals the decrypted session 
1(P request signature, RAPI proceeds to end the current session (block 1425). 

y 2 Returning to Figure 9, after it ends a session, RAPI 1550 generates a new 

authority certificate (block 1685). As described above, Figure 15 shows the process of 
L generating an authority certificate. RAPI 1550 then sends the new authority 
O certificate back to the access driver 1545 (block 1690). Upon receiving the new 
153 authority certificate, access driver 1545 updates the current authority certificate with 
information in the new certificate (block 1695). Accordingly, the information in the 
new authority certificate will be used to generate requests in subsequent sessions. 

Figure 9 shows that access driver generates only one service request in a work 
session. In practice, a plurality of service requests may be generated and sent to 
20 RAPI 1550 between each work session. 

In summary, the present invention requires the inclusion of a digital 
signature in session and service requests as a security measure to prevent 
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components foreign to the system, such as viruses, to invoke BIOS functions or 
services. Furthermore, each successive session or service request includes a digital 
signature that is generated using a new private key to prevent foreign components 
from capturing and replaying the session and /or service requests and causing 
adverse effects to the system. Thus, the security measure employed in the present 
invention ensures safe and secured utilization of BIOS functions. 

Although the present invention has been described in terms of certain 
preferred embodiments, other embodiments apparent to those of ordinary skill in 
the art are also within the scope of this invention. Accordingly, the scope of the 
invention is intended to be defined only by the claims which follow. 
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CLAIMS : 

What is claimed is: 

1 1. A system for accessing and executing instruction sequences in a 

2 physical memory from a virtual memory in a processor-based system, comprising: 

3 a memory for storing instruction sequences by which the processor- 

4 based system is processed, the memory including a physical memory and a virtual 

5 memory; and 

6 a processor for executing the stored instruction sequences; and 

fi wherein the stored instruction sequences include process steps to cause 

i ! the processor to: (a) map a plurality of predetermined instruction sequences from 

f= the physical memory to the virtual memory; (b) determine an offset to one of said 

lli plurality of predetermined instruction sequences in the virtual memory; (c) receive 

it* an instruction to execute the one of said plurality of predetermined instruction 

if 3 sequences; (d) transfer control to the one of said plurality of predetermined 

lp instruction sequences; and (e) process the one of said plurality of predetermined 

14 instruction sequences from the virtual memory. 

1 2. The system of Claim 1, wherein in step (c), the instruction is made 

2 from an application program. 

1 3. The system of Claim 1, wherein in step (c), the instruction is made 

2 from a class driver. 
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1 4. The system of Claim 1, wherein step (a) comprises the steps of: 

2 (a.l) mapping a plurality of BIOS instruction sequences from the 

3 physical memory to the virtual memory, said BIOS instruction sequences including 

4 a BIOS service directory; and 

5 (a.2) mapping BIOS data from the physical memory to the virtual 

6 memory. 

1 5. The system of Claim 4, wherein step (b) comprises the steps of: 

2 (b.l) determining a starting virtual address of the BIOS service 

3 directory; and 

4_ (b.2) determining a starting virtual address of one of the plurality of 

f S BIOS instruction sequences by reference to the BIOS service directory. 

f ; 6. The system of Claim 5, wherein step (d) comprises the steps of: 

27 (d.l) creating a register stack in a memory location; 

33 (d.2) identifying a location of the starting virtual address of one of the 

4J plurality of BIOS instruction sequences in the register stack; and 

p (d.3) transferring control to the one of the plurality of BIOS instruction 

6 sequences. 

1 7. The system of Claim 6, wherein in step (d.l), the memory location is a 

2 buffer located in a dynamic random access memory (DRAM). 
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1 8. The system of Claim 6, wherein in step (d.l), the memory location is a 

2 buffer located in a main memory. 

1 9. The system of Claim 6, wherein step (e) comprises the steps of: 

2 (e.l) determining if the starting virtual address is within a range of 

3 addresses mapped from the physical memory to the virtual memory; and 

4 (e.2) if so, executing the one of the plurality of BIOS instruction 

5 sequences from the virtual memory, otherwise indicating that the starting virtual 
! j address is not within the range of addresses mapped from the physical memory to 
% : j the virtual memory. 



f=j 10. A method for accessing and executing instruction sequences in physical 

memory from virtual memory in a processor-based system, comprising the steps of: 
J3 (a) mapping a plurality of predetermined instruction sequences from 

|3 the physical memory to the virtual memory; 

5 (b) determining an offset to one of said plurality of predetermined 

6 instruction sequences in the virtual memory; 

7 (c) receiving an instruction to execute the one of said plurality of 

8 predetermined instruction sequences; 

9 (d) transferring control to the one of said plurality of predetermined 

10 instruction sequences; and 

11 (e) processing the one of said plurality of predetermined instruction 

12 sequences from the virtual memory. 
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11. The method of Claim 10, wherein in step (c), the instruction is made 
from an application program. 



1 12. The method of Claim 10, wherein in step (c), the instruction is made 

2 from a class driver. 

1 13. The method of Claim 10, wherein step (a) comprises the steps of: 

2 (a.l) mapping a plurality of BIOS instruction sequences from the 

3 physical memory to the virtual memory, said BIOS instruction sequences including 

4 a BIOS service directory; and 

5 (a.2) mapping BIOS data from the physical memory to the virtual 
memory. 

% 14. The method of Claim 13, wherein step (b) comprises the steps of: 

| (b.l) determining a starting virtual address of the BIOS service 

directory; and 

4 (b.2) determining a starting virtual address of one of the plurality of 

g BIOS instruction sequences by reference to the BIOS service directory. 

1 15. The method of Claim 14, wherein step (d) comprises the steps of: 

2 (d.l) creating a register stack in a memory location; 

3 (d.2) identifying a location of the starting virtual address of one of the 

4 plurality of BIOS instruction sequences in the register stack; and 
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5 (d.3) transferring control to the one of the plurality of BIOS instruction 

6 sequences. 

1 16. The method of Claim 15, wherein in step (d.l), the memory location is 

2 a buffer located in a dynamic random access memory (DRAM). 

1 17. The method of Claim 15, wherein in step (d.l), the memory location is 

2 a buffer located in a main memory. 

t[ 18. The method of Claim 15, wherein step (e) comprises the steps of: 

ij (e.l) determining if the starting virtual address is within a range of 

3E addresses mapped from the physical memory to the virtual memory; and 
43 (e.2) if so, executing the one of the plurality of BIOS instruction 



If; sequences from the virtual memory, otherwise indicating that the starting virtual 
<H address is not within the range of addresses mapped from the physical memory to 
p : the virtual memory. 



1 19. Computer-executable process steps for accessing and executing 

2 instruction sequences in physical memory from virtual memory in a processor- 

3 based system, the process steps including: 

4 (a) mapping a plurality of predetermined instruction sequences 

5 from the physical memory to the virtual memory; 

6 (b) determining an offset to one of said plurality of predetermined 

7 instruction sequences in the virtual memory; 
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8 (c) receiving an instruction to execute the one of said plurality of 

9 predetermined instruction sequences; 

10 (d) transferring control to the one of said plurality of predetermined 

11 instruction sequences; and 

12 (e) processing the one of said plurality of predetermined instruction 

13 sequences from the virtual memory. 

1 20. Computer-executable process steps of Claim 19, wherein in step (c), the 

2 instruction is made from an application program. 

1 21. Computer-executable process steps of Claim 19, wherein step (a) 

2,. comprises the steps of: 



|f (a.l) mapping a plurality of BIOS instruction sequences from the 

#1 physical memory to the virtual memory, said BIOS instruction sequences including 

§1 a BIOS service directory; and 

6 (a.2) mapping BIOS data from the physical memory to the virtual 



If memory. 

p 22. Computer-executable process steps of Claim 21, wherein step (b) 

2 comprises the steps of: 

3 (b.l) determining a starting virtual address of the BIOS service 

4 directory; and 

5 (b.2) determining a starting virtual address of one of the plurality of 

6 BIOS instruction sequences by reference to the BIOS service directory. 
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1 23. Computer-executable process steps of Claim 22, wherein step (d) 

2 comprises the steps of: 

3 (d.l) creating a register stack in a memory location; 

4 (d.2) identifying a location of the starting virtual address of one of the 

5 plurality of BIOS instruction sequences in the register stack; and 

6 (d.3) transferring control to the one of the plurality of BIOS instruction 

7 sequences. 

1 24. Computer-executable process steps of Claim 23, wherein in step (d.l), . 

2 the memory location is a buffer located in a dynamic random access memory 
3_ (DRAM). 

f ;f 25. Computer-executable process steps in Claim 23, wherein in step (d.l), 

2ft the memory location is a buffer located in a main memory. 

C 26. Computer-executable process steps of Claim 23, wherein step (e) 

2y comprises the steps of: 

3D (e.l) determining if the starting virtual address is within a range of 

4 addresses mapped from the physical memory to the virtual memory; and 

5 (e.2) if so, executing the one of the plurality of BIOS instruction 

6 sequences from the virtual memory, otherwise that the starting virtual address is 

7 not within the range of addresses mapped from the physical memory to the virtual 

8 memory. 
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1 27. A system for accessing instruction sequences in a physical memory 

2 from a virtual memory in a processor-based system, comprising: 

3 a memory for storing instruction sequences by which the processor- 

4 based system is processed, the memory including a physical memory and a virtual 

5 memory; and 

6 a processor for executing the stored instruction sequences; and 

7 wherein the stored instruction sequences include process steps to cause 



8 the processor to: (a) map a plurality of predetermined instruction sequences from 

9 the physical memory to the virtual memory; (b) determine an offset to one of said 

10 plurality of predetermined instruction sequences in the virtual memory; (c) receive 

11 an instruction to execute the one of said plurality of predetermined instruction 
1|? sequences; (d) transfer control to the one of said plurality of predetermined 

1 J? instruction sequences; and (e) process the one of said plurality of predetermined 

lin instruction sequences from the virtual memory. 



f I 28. The system of Claim 27, wherein step (a) comprises the steps of: 

|j (a.l) mapping a plurality of BIOS instruction sequences from the 

33 physical memory to the virtual memory, said BIOS instruction sequences including 

4 a plurality of BIOS read only memory (ROM) instruction sequences and a BIOS 

5 service directory; and 

6 (a.2) mapping BIOS data from the physical memory to the virtual 

7 memory. 
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1 29. The system of Claim 28, wherein step (b) comprises the steps of: 

2 (b.l) determining a starting virtual address of the BIOS service 

3 directory; and 

4 (b.2) determining a starting virtual address of one of the plurality of 

5 BIOS instruction sequences by reference to the BIOS service directory. 

1 30. The system of Claim 29, wherein step (d) comprises the steps of: 

2 (d.l) creating a register stack in a memory location and; 

3 (d.2) identifying a location of the starting virtual address of one of the 

4 plurality of BIOS ROM instruction sequences in the register stack. 

|3 31. The system of Claim 30, wherein step (e) comprises the steps of: 

SH (e.l) determining if the starting virtual address is within a range of 

g? addresses mapped from the physical memory to the virtual memory; and 

|J (e.2) if so, reading the one of the plurality of BIOS ROM instruction 



§ sequences from the virtual memory, otherwise indicating that the starting virtual 
g address is not within the range of addresses mapped from the physical memory to 
h the virtual memory. 



1 32. A method for accessing instruction sequences in physical memory 

2 from virtual memory in a processor-based system, comprising the steps of: 

3 (a) mapping a plurality of predetermined instruction sequences from 

4 the physical memory to the virtual memory; 
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5 (b) determining an offset to one of said plurality of predetermined 

6 instruction sequences in the virtual memory; 

7 (c) receiving an instruction to execute the one of said plurality of 

8 predetermined instruction sequences; 

9 (d) transferring control to the one of said plurality of predetermined 

10 instruction sequences; and 

11 (e) processing the one of said plurality of predetermined instruction 

12 sequences from the virtual memory. 

1 33. The method of Claim 32, wherein step (a) comprises the steps of: 

2 (a.l) mapping a plurality of BIOS instruction sequences from the 

|5 physical memory to the virtual memory, said BIOS instruction sequences including 

4J a plurality of BIOS read only memory (ROM) instruction sequences and a BIOS 

# ; service directory; and 

p (a.2) mapping BIOS data from the physical memory to the virtual 

%l memory. 

fi 34. The method of Claim 33, wherein step (b) comprises the steps of: 

2 (b.l) determining a starting virtual address of the BIOS service 

3 directory; and 

4 (b.2) determining a starting virtual address of one of the plurality of 

5 BIOS instruction sequences by reference to the BIOS service directory. 

1 35. The method of Claim 34, wherein step (d) comprises the steps of: 
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2 (d.l) creating a register stack in a memory location; and 

3 (d.2) identifying a location of the starting virtual address of one of the 

4 plurality of BIOS ROM instruction sequences in the register stack. 

1 36. The method of Claim 35, wherein step (e) comprises the steps of: 

2 (e.l) determining if the starting virtual address is within a range of 

3 addresses mapped from the physical memory to the virtual memory; and 

4 (e.2) if so, reading the one of the plurality of BIOS ROM instruction 

5 sequences from the virtual memory, otherwise indicating that the starting virtual 

6 address is not within the range of addresses mapped from the physical memory to 

7 the virtual memory. 



j:;; 37 a system to securely utilize Basic Input and Output System (BIOS) 

21 services, comprising: 

jp an access driver to generate a service request to utilize BIOS services, 

P the service request including a service request signature created using a private key 

|C in a cryptographic key pair;. and 

p an interface to verify the service request signature using a public key in 

j§ the cryptographic key pair to ensure the integrity of the service request. 

1 38. The system of Claim 37, wherein: 

2 the access driver generates a session request to establish a session with 

3 the interface; and 
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4 the session request includes a session request signature created using a 

5 private key in a cryptographic key pair. 

1 39. The system of Claim 37, wherein: 

2 the access driver generates a session request to end the session with the 

3 interface; and 

4 the session request includes a session request signature created using a 

5 private key in a cryptographic key pair, 

0 40. The system of Claim 37, wherein: 

2f the interface generates an authority certificate and sends the authority 

t certificate to the access driver after receiving a session request; and 

W the access driver uses information included in the authority certificate to 

ft generate subsequent session requests. 

13 41. The system of Claim 40, wherein the authority certificate includes a 

2 new public key. 

1 42. The system of Claim 40, wherein the authority certificate includes a 

2 new private key. 

1 43. The system of Claim 40, wherein the authority certificate includes a 

2 certificate signature. 
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1 44. The system of Claim 37, wherein: 

2 the interface generates an authority certificate and sends the authority 

3 certificate to the access driver after receiving the service request; and 

4 the access driver uses information in the authority certificate to generate 

5 subsequent service requests. 

1 45. A method to securely invoke Basic Input and Output System (BIOS) 

2 services, comprising: 

|; creating a service request to invoke BIOS services; 

signing the service request with a service request signature generated 

III using a private key in a cryptographic key pair; and 

% verifying the service request signature using a public key in the 

f 3 cryptographic key pair to ensure the integrity of the service request. 

f 3 46. The method of Claim 45, further comprising: 

2 creating an authority certificate that includes a new private key and a 

3 new public key after processing the service request; 

4 signing a subsequent service request with a service request signature 

5 generated using the new private key; and 

6 verifying the service request signature of the subsequent service 

7 request using the new public key. 

1 47. The method of Claim 45, further comprising: 

002603.P002X -64- 
KGN/SND/phs 



2 performing a BIOS service indicated by a service operation code 

3 included in the service request. 

1 48. The method of Claim 45, further comprising: 

2 creating a session request to establish a session with a ROM Application 

3 Program Interface (RAPI); 

4 signing the session request with a session request signature generated 

5 using a private key in a cryptographic key pair; and 

6 verifying the session request signature using a public key in the 
f .; cryptographic key pair to ensure the integrity of the session request. 

f ■ 49. The method of Claim 48, further comprising: 

|-: creating an authority certificate that includes a new private key and a 

3M= new public key after processing the session request; 

|3 signing a subsequent session request with a session request signature 

j;;f generated using the new private key; and 

6 verifying the session request signature of the subsequent session 

7 request using the new public key. 

1 50. The method of Claim 45, further comprising: 

2 creating a session request to end a session with a ROM Application 

3 Program Interface (RAPI); 

4 signing the session request with a session request signature generated 

5 using a private key in a cryptographic key pair; and 
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6 verifying the session request signature using a public key in the 

7 cryptographic key pair to ensure the integrity of the session request. 

1 51. A computer program embodied on a computer-readable medium to 

2 securely utilize Basic Input and Output System (BIOS) services, comprising: 

3 an access driver to generate a service request to utilize BIOS services, 

4 the service request including a service request signature created using a private key 

5 in a cryptographic key pair; and 

6 an interface to verify the service request signature using a public key in 
7V the cryptographic key pair to ensure the integrity of the service request. 

1% 52. A computer data signal embodied in a data stream, comprising: 

2n an access driver to generate a service request to utilize BIOS services, 

3m ; the service request including a service request signature created using a private key 

4Q in a cryptographic key pair; and 

5^' an interface to verify the service request signature using a public key in 

6 the cryptographic key pair to ensure the integrity of the service request. 



002603.P002X 
KGN/SND/phs 



ABSTRACT 



In accordance with one aspect of the current invention, the system comprises 
a memory for storing instruction sequences by which the processor-based system is 
processed, where the memory includes a physical memory and a virtual memory. 
The system also comprises a processor for executing the stored instruction 
sequences. The stored instraction~sequ£nces include process acts to cause the 
processor to: map a plurality of predetermined instruction sequences from the 
physical memory to the virtual memory, determine an offset to one of the plurality 
of predetermined instruction sequences in the virtual memory, receive an 
instruction to execute the one of the plurality of predetermined instruction 
sequences, transfer control to the one of the plurality of predetermined instruction 
sequences, and process the one of the plurality of predetermined instruction 
sequences from the virtual memory. In accordance with another aspect of the 
present invention, the system includes an access driver to generate a service request 
to utilize BIOS services such that the service request contains a service request 
signature created using a private key in a cryptographic key pair. The system also 
includes an interface to verify the service request signature using a public key in the 
cryptographic key pair to ensure integrity of the service request. 
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Introduction 

TJus document provides the interface for the 32-Bit BIOS Power Management Service Interface (BPMSI) 
This interface is used by the Windows NT Power Management Kernel driver for providing power 
management services to APM-aware applications. 

Terms 

APM BIOS 

System BIOS which provides power management functions adhering to the APM specification (currently at 
revision level 1.2) 



Kernel Mode 

A privileged processor mode in which the NT system code runs. A kernel mode thread has access to all I/O 
and system memory 

Power Management Kernel Driver (PM Driver) 

Provides access to the BIOS ROM, BIOS Data Area and the 32-Bit Services for Services. 

Power Management Service (PM Service) 

Provides power management services for applications and other drivers. Translates their requests into 
quenes to the BIOS Power Management Service Interface using the interface provided by the Power 
Management Kernel Driver (PM Driver). 

PowerPAL 

Phoenix s APM BIOS extensions which provide application level access to system and device power 
management features 

System Idle 

State where PM service detected minimum processing at the application level. In this state, only threads run 
on idle priority are executed and they will be preempted by any thread running in a higher priority class. 

User Mode 

A non-privileged processor mode in which application code runs. An user-mode thread does not have 
access to I/O and system memory. 
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Architecture Overview 

The extensions to the BIOS for support of Windows NT power management consist of two pans: 

(a) Modifications to the BIOS32 Service Directory. An entry was added which allows the PM Driver to 
find the entry point for the BIOS Power Management Service Interface. 

(b) New 32-Bit BIOS Power Management Service, which mimics the APM 32-bit interface with some 
differences, which are noted below. The new interface provides a 0:32 calling method which is more 
secure and more Windows NT friendly. 

When the PM Kernel wishes to use the BIOS services, it must perform the following steps: 

1 . Find the BIOS32 Service Directory header 

2. Call the BIOS32 Service Directory calling interface, specifying the 32-Bit BIOS Power Management 
Service Interface entry point. 

3. Call the BIOS 32-Bit BIOS Power Management Service Interface entry point, asking for APM 
Connect. 

BIOS32 Service Directory Modifications 

The 32-bit BIOS Service Directory is an existing structure within the Phoenix BIOS which allows a 32-bit 
protected mode application or operating system to find the entry point for a particular 32-bit service. This 
specification defines a new standard 32-bit BIOS Service. 

The BIOS32 Service Directory consists of a fixed structure which can be detected by the PM driver and a 
single function which returns the address for a particular service. 

The BIOS32 Service Directory Header 

A BIOS which implements the BIOS32 Service Directory must embed a specific, contiguous 16-byte 
pattern somewhere in the physical address range OEOOOOh - OFFFFFh. The pattern must be paragraph 
aligned (i.e., it must start on a 16-byte boundary). This pattern is known as the BIOS32 Service Directory 
Header. 



The Header is comprised of six distinct fields. The following table describes each field. 



QfSete | 




+ Description*.- v*"- * - 1; : *-■* * ; * < : • v*v^^H^^*^v5S~?l 


: 0 


4 bytes 


j The ASCII signature ".32 w or 0x5F33325F 


4 


, 4 bytes 


j The entry point for the B30S32 Service Directory calling interface. This is a 32-bu 
i linear (i.e., not segmenttoffset) physical address 


. 8 


1 byte 


! The revision level of the BIOS32 Service Directory header and calling interface. The 
current revision is 0. 


9 


I byte 


The length of the BIOS32 Service Directory header. Measured in paragraphs (16 j 
> bytes). The current length is I. — 


10 


I byte 


; The BIOS32 Service Directory header byte-wide, byte-sum checksum. When totaled, 
! all of the bytes in the header should ad up to 0. 


II 


5 bytes 


' Reserved. Should be 0. 



Clients of the BIOS32 Service Directory should fust determine its existence by locating the Header. This is 
done by scanning OEOOOOh to OFFFFOh in paragraph increments and looking for a signature match ("_32 J*) 
in the first 4 bytes of each paragraph. When, and if, the signature is detected the client should perform a 
checksum of all bytes in the Header. (The Header length, in paragraphs, is found at ofTset 9h.) All byies in 
the Header should ADD together with a result of Oh. If the checksum is valid then the 32-bit entry point 
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fieid can be used as the address for the BIOS32 Service Directory Calling Interface. If the Header is not 
found then the BIOS32 Service Directory does not exist on the platform. 

The BIOS32 Service Directory entry point, and its associated code and data, maybe located anywhere 
within the 4Gb physical address space. However, it is guaranteed to be physically contiguous (i.e.. it will be 
delivered in ROM or FLASH space) and to fit within two pages (i.e., it will not span three pages). 



The BIOS Service Directory 

To get the entry point to the BIOS 32-Bit Power Management Service Interface, the PM Driver must call 
the BIOS Service Directory with the following parameters: 

"NTPM"or0x4E54504D 
0x00000000 

Error code: 0x00 = None, 0x81 = Service does not exist 
Base address of the 32-Bit Power Management Service code 
Length of the 32-bit Power Management Service code (from EBX) 
Offset (from EBX) of the 32-bit Power Management Service code entry point. 

The entry point of the 32-bit Power Management Service code entry point is FAR (that is, 
requiring both segment and offset to be pushed on the stack.) 

CS : The base address must be less than or equal to the (4KB) page address of the page that contains the 
entry point. For example, if the entry point is 0FFF81234h. then the base address must be less than 
or equal to 0FFF8 lOOOh. The limit must be such that the base address plus the limit generate an 
address that is greater than or equal to the last address on the (4KB) page which follows the page 
containing the entry point. For example, if the entry point is 0FFF81234h then the base address 
plus the limit must be greater than or equal to 0FFF82FFFh. Simply stated, the base address and 
the limit must "encompass' both the page that contains the entry point and the following page. 

The segment type must be 100b (code, execute only) or 101b (code, execute/read). However, the 
implemented of the Service Directory cannot assume read access to the CS code segment. The 
system bit must be 1 (non-system segment). It is recommended that the Descriptor Privilege Level 
(DPL) be 0. (The CS descriptor DPL becomes the Current Privilege Level, or CPL). If the CPL is 
not 0. then the OS must provide trapping and vinuaii2ation services for ring 0 privileged 
instructions (such as those that access CRx). Note also the dependency of this field on the IOPL 
field in EFLAGS (see SectionO). 

The Default Size bit must be I (32 bits). 

DS: The base address must be equal to the CS base address. The limit must be greater than or equal to 
the CS limit. 

The segment type must be 000b (data, read only) or 001 (data, read/write). However, the 
implemented of the Service Directory cannot assume write access to the DS data segment. The 
system bit must be 1 (non-system segment). The Descriptor Privilege Level (DPL) must be greater 
than or equal to CPL (see the DPL field in Section 0). 



IN: 



OUT: 



EAX 

EBX 

AL 

EBX 

ECX 

EDX 
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SS: The segment type must be 01 lb (data, read/write, expand-down) or OOib data, read/write, expand- 
up). The system bit must be 1 (non-system segment). The Descriptor Privilege Level (DPL) must 
be equal to the CPL (see the DPL field in Section 0). The Default Size bit must be i (32 bits). The 
Granularity bit must be 1 (4Kb). 

Note that the above settings ensure a stack size of at least 4kb. It is the caller's responsibility to 
ensure that there is at least Ikb of unused stack available. 

Paging: Paging may or may not be enabled. If paging is enabled, then the address space that is described by 
the CS and DS selectors must be linearly contiguous. That is, the original physical contiguity of the 
Calling Interface as found in ROM or FLASH must be preserved. (The Calling Interface code and 
data is written to be position-independent and ElP-relaiive). 

IOPL: In order for the Calling Interface to execute I/O instructions, the I/O Privilege Level (IOPL) field 
in EFLAGS must be greater than or equal to the CPL (sec the DPL field in Section 0). 

Other: The BIOS Data Area, Extended BIOS Data Area and fixed-location ROM data tables cannot be 
assumed to be available for use by the executing code because of paging. The BDA may be 
accessed using the pointer provided by the caller. 



32-Bit BIOS Power Management Service Interface 

In general, the 32-Bit BIOS Power Management Interface provides the same functionality as the 32-bit 
APM entry point. There are two areas of difference; the way in which calling parameters are passed and the 
way in which certain APM connect functions are supported. 

Calling Parameters 

The APM 32-Bit Interface passes all parameters in CPU registers. The BIOS Power Management Service 
Interface passes the parameters on the stack. The equivalent C-style declaration would be: 

typedef struct 

{ 



ULONG 


reservedO ; 


/* 


00 


•/ 


ULONG 


pBDA; 




/* 


04 


*/ 


ULONG 


regFlags ; 


/* 


08 


*/ 


ULONG 


reservedl ; 


/* 


oc 


*/ 


ULONG 


reserved2 ; 


/* 


10 


*/ 


ULONG 


reserved3 ; 


/* 


14 


•/ 


ULONG 


reserved4 ; 


/* 


18 


*/ 


ULONG 


reservedS ; 


/* 


1C 


V 


ULONG 


reserved6 ; 


/* 


20 


V 


ULONG 


reserved? ; 


/* 


24 


V 


ULONG 


reserved8 ; 


/* 


28 


V 


ULONG 


reserved9 ; 


/* 


2C 


•/ 


ULONG 


regEBP ; 




/* 


30 


•/ 


ULONG 


regEDI ; 




/* 


34 


*/ 


ULONG 


regESI, 




/♦ 


38 


•/ 


ULONG 


regEDX 




/* 


3C 


*/ 


ULONG 


regECX 




/* 


40 


•/ 


ULONG 


regEBX 




/♦ 


44 


*/ 


ULONG 


regEAX 




/* 


48 


*/ 



} regStruct; 



unsigned char BPMSI (regStruct* parameters); 
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The actual APM function and its behavior will be determined by the value written in the corresponding 
register fields. The pBDA field is a pointer to the virtual address where the kernel driver has mapped the 
BIOS Data Area so that it can be accessed by the service entrance. 

If an error occurs, bit 0 of regFlags will be i and the error code will be in bits 8-15 of regEAX otherwise it 
will be 0 and bits 8* 15 of regEAX will be 0. The error codes are identical to those found in the APM 1 .2 
specification. 
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Software Requirements 



Development Software Requirements 

The following software development tools are required to build the PM service: 

• MASM 6.1 1 c assembler from Microsoft 

• Phoenix PhDebug for debugging the code 

Software Requirements 

PM service requires to ran on the following environment: 

• Windows NT 4.0 

• System with Phoenix NottBIOS supporting the NT BIOS Interface to the PowerPAL 

• PM driver installed in the system 



Porting Changes 

The following section describes the files which have been modified in the Core, Miser and the chipset code. 
It also describes the changes which need to be made in order to port a normal BIOS to include the NT 
support. 
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1.0 Overview 



The PhoenixPhlash flash utility will be used to program BIOS images into flash ROMs in 
AT compatible systems. The utility will consist of the following files: 

PHLASHNT.EXE - used to program the flash ROM 
PLATFORM.DLL - used to perform platform dependent functions 
BIOS.ROM - actual BIOS image to be programmed into flash ROM 

This specification provides a detailed description of the functionality for the 
PHLASHNT.EXE program. Because PLATFORM.DLL and BIOS.ROM are platform 
specific, only the general format of these two files is covered in this document 

PhoenixPhlash will be executed as a Win32 console application. 

High priority is being placed on flexibility, adaptability and supportability for this design 
project. As much customization capability as possible will be placed into the 
PLATFORM.DLL file so that many different platforms and configurations can be 
supported without modifying PHLASHNT.EXE. PhoenixPhlash will support platforms 
with a single flash ROM part, as well as platforms with multiple flash ROMs. Flash 
ROMs from 1Mbit to 4Mbits or greater will be accommodated, including boot block 
devices and devices with any configuration of multiple Cashable regions. 

For each supported part, all code specific to the particular flash ROM part (e.g. Intel 
28Fxxxx) will be part of the PHLASHNT.EXE module. All code and parameters specific 
to a platform (e.g. flash enable code and flash ROM address range) will be pan of the 
PLATFORM.DLL module. 

PHLASHNT.EXE, the main module of the PhoenixPhlash utility, will contain all code 
which is platform independent It will contain user interface code, code to load and 
verify the PLATFORM J)LL file and the platform independent portions of code to 
program a flash device. 

PHLASHNT.EXE will be a Win32 executable file, generated using Microsoft C++ V4.2 
or later. 



Using CDriver to access hardware 

PHLASHNT.EXE uses the CDriver C++ class which works in conjunction with the 
PhoenixAD driver to enable Windows NT user-mode applications to access I/O ports; to 
access BIOS data and code area; and to execute BIOS32 services. The CDriver class 
provides a simple and flexible interface between the application program and the 
PhoenixAD driver. 

CDriver works in conjunction with the PhoenixAD driver to provide the following 
functions to user-mode application programs. 

Access to I/O ports 

Execute I310S32 services 
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Access the BIOS image 

Access BIOS data areas 

Read the system Real Time Clock 
The CDriver class serves as a thin wrapper interface between Windows NT applications 
and the PhoenixAd driver. It encapsulates the interface to the driver and provides 
flexibility to both applications and the kernel driver designs. 

To assure future compatibility, PHLASHNT.EXE does not call the PhoenixAD driver 
directly; instead, it calls the methods in the CDriver class. 
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2.0 Modes of Operation 



2.1 Win32 Console 

PHLASHNT.EXE will be started in t Windows NT window, followed by optional 
command line flags (if any). 

Command line flags will include (both lower and upper case characters are acceptable): 
/A 

AUTODETECT OFF - Do not read ID from the part. By default, program 
verifies that the manufacturer ID and part ID read from the part, matches the 
ID specified in the PLATFORM.DLL file and when the two IDs differ, the ID 
read from the part is used. This allows one to use the same PLATFORM.DLL 
and BIGS.ROM for several different parts without the need to modify either 
of the two files. When this flag is not set, then it is assumed that the ID is 
"readable" from the part. When this flag is set, the ID from the part is not 
used, instead the values specified in the PLATFORM.DLL are used. 

fB m Jilename 

BINARY FILE - Overrides the default platform specific binary file. This 
option is required when a full path specification is needed and/or the binary 
file has a name other than PLATFORMDLL. 

/b\J m ft!ename 

BACKUP - Save the previous version of the BIOS image into file filename 
before erasing. Filename is optional; if not specified, the previous image is 
stored in B10S.BAJC Because many versions of BIOS use platform 
dependent features such as shadow memory and de-compression, it is often 
necessary to use platform dependent code in PLATFORM.DLL to retrieve the 
BIOS image before it can written to a file. 



CMOS UPDATE - Clears the CMOS checksum after Flash is updated. If the 
AUTO UPDATE feature is installed in the new BIOS image, the BIOS 
automatically sets all CMOS fields to their default values on the next boot If 
the AUTO UPDATE feature is not loaded, the BIOS displays the CMOS 
checksum error message on the next boot and prompts the user to press the F2 
key to execute Setup and manually reconfigure the machine. 



CHECKSUM BIOS ROM - Computes checksum on BIOS ROM image. If 
the checksum is not zero, or if the optional PLATFORM.DLL function 
CheekSum fails, the program terminates with an error message. 

USAGE - Display program name, version, copyright and help screen. /? can 
also be used for this option. 
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/I 

IMAGE SIZE VERIFICATION - Proceed only if the ROM image file size is 
the same as the size of the flash part 

/MODE-n 

OPERATION - Selects the operating mode for PHLASHNT. The following 
operating modes are currently supported: 

0 Update only the BIOS image (the normal operating mode). In this mode, 
PHLASHNT replaces the current BIOS image with the new image. The 
DMI information in the system BIOS is maintained. This is the default 
mode and is selected if the /MODE command line flag isn't present or if 
an operating mode isn't specified. 

1 Update only the DMI information. In this mode, PHLASHNT writes the 
strings specified via the DMI command line flags to the Flash. The DMI 
information in the system BIOS is maintained unless new DMI strings are 
specified on the command line. 

2 Update both the BIOS and DMI information (save system DMI strings). 
In this mode, PHLASHNT both replaces the current BIOS image and 
writes the strings specified via the DMI command line Sags to Flash. The 
DMI information in the system BIOS is maintained unless new DMI 
strings are specified on the command line. 

3 Update both the BIOS and DMI information (reset system DMI strings). 
In this mode, PHLASHNT both replaces the current BIOS image and 
writes the strings specified via the DMI command line flags to Flash. The 
DMI information in the system BIOS is replaced with the DMI strings 
from the new BIOS ROM image and/or new DMI strings specified on the 
command line. 

These options are not displayed by the help (/H) option for security reasons. 



NEW (different) - Proceed only for different version of BIOS ROM. If the 
data structure at BCPSYS, which includes BIOS version and build date & 
time, is same as the corresponding structure in the BIOS.ROM file then the 
programs terminates without flashing. 



OVERRIDE PLATFORM.DLL OPTIONS - Disable all flags set in 
PLATFORM.DLL. Without this switch, options set in the PLATFORM.DLL 
are combined with options specified on the command line. When this switch is 
used, only command line options are used. 



PRODUCTION - Maximize speed of flashing. All usei feedback is reduced 
to a minimum (no sound, or screen update). This is used to reduce the time 
needed to flash a part in a production environment. Only the final 
success/failure is reported. 



PhoanlxPHLASN - 1 a»h ROM Programming Utility for Window WT D»»lgn 3p»cKlcatlon 



/PN 

BIOS PART NUMBER CHECK • Proceed only if the BIOS part number m 
BIOS. ROM is the same as the part number is the current BIOS. 

/PF="iist of options" J 

Command line options to be passed to the platform dependent module 
PLATFORM.DLL. On some platforms it may be desirable to pass command 
line options to the platform dependent procedures. This is done via the 
CmdLmeO function. When both the CmdLineO address is non-zero and this 
command line option is present, then the string immediately following the 
equal sign will be passed to PLATFORM.DLL (enclose the string in double 
quotes if the string includes spaces). 

/Rn 

RETRY - If flashing a block fails, retry n times instead of aborting. 

The /Rn option can be used in crisis mode by setting psiRetryCount with the 

desired retry count in PLATFORM.CPP. 

/S 

SILENT ♦ Silent operation without audio feedback. 

/V 

VERIFY - After each block is programmed, data is the flash part address 
space will be compared to the data in the BIOS .ROM file. Any discrepancies 
are reported and the program will either re-try programming of the same block 
or the system will halt (depending on the response to a prompt). Because the 
check is made after the flash memory was erased, the system will be very 
unstable and it may not be possible to properly notify the user and recover. 

IZ 

ZERO BLOCKS - Zero flash blocks before erasing. 



BIOS ROM image file name. Any command line option without the leading 
back-slash will be interpreted as the file name for the BIOS ROM liriagc 
A filename is only required when necessary to specify a full pato for me ROM 
BIOS image and/or the ROM BIOS image file is different than BIOS.ROM. 

^filename , . 

Response file. Any of the command line options described above may be 
placed in a response file. PHLASHNT will read the file and process the 
options as though they were entered on the command line. The options may 
be placed on a single line or on separate lines. Each line may be up to 1024 
characters in length. 

The following command line flags are used to write irfomation to Flash for later 
retrieval through the Phoenix Desktop Management Interface (DMn. DM1 command line 
flags are ignored if the target BIOS image does , not support the DMI 
have a DMI BCP structure installed) or the PHLASHNT operation mode is BIOS only 
(see above). 
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All flags have the format fDxxString, where xr is one or two characters identifying the 
specific DMI stnng (see below). DMI command line flags are optional; U, if » gjveo 
DMI command line flag isn't specified, the previous contents of the corresponding DM! 
string buffer aren t modified, unless a default siring is specified in PLATFORM.DLL In 

w ^"^/"i*?" 1 ^ dw ?£ dcfault strin S » *c corresponding DMI strine 

buffer. If a DMI command flag is specified without tne String field/the corresponding 

buffcr " 5 leared (« » ,» anil «nng). String can only contain printable 
ASCII characters [ Stnng must be enclosed in ouotes if it contains spaces. Tne maximum 
length of each DMI stnng is platform specific; PHLASHNT returns an error if the passed 
stnng is longer than the corresponding tareet buffer. The following DMI fields are 
reasons* SUp? ° ned ' ThcSC 0pUoas we not ™Pl*y*d by the help (/H) option for securiry 

/DSS String Specifies the system serial number string. 

/DMSString Specifies the system manufacturer'! name string. 

/DPS String Specifies the system product (model) identification string. 

/DVS String Specifies the system version string. 

fDSU-String Specifies the motherboard serial number string. 

/DMMString Specifies the motherboard manufacturer's name string. 

fD?MStrlng Specifies the motherboard product (model) identification string. 

/DVM-String Specifies the motherboard version string. 

^DSC String Specifies the chassis serial number string. 

fDMCString Specifies the ehasiis manufacturer's name siring. 

/D?CString Specifies the ehaasis product (model) identification string. 

/DVCString Specifies the chassis version string. 

fDOVStrlng Specifies OEM string 1. 

fDOnStrUtg Specifies OEM string a. 

The system and chassis switches axe available only with DMI version 2.0. 

The older forms of the command line switches, given below, were originally for DMI \2 
and are kept for compatibility. These are equivalent to /DSM, /DMM t /DPM and /DVM 
respectively. 

fDSString Specifies the motherboard serial number string* 

/DMString Specifies the motherboard manufacturer's name string. 

fD? String Specifies the motherboard product (model) identification string. 
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/DV String Specifies the motherboard version string. 

Next, the flash program will fold the PLATFORM.DLL file and' call the olatform 
flSS^Pl^^ PLATFORM.DLL to prepare Z XatCTr 

nasmng. PLATFORM.DLL will indicate memory region where the BIOS ROM image is 
to be loaded in memory and will indicate what memory regions to use for CTash 

ttoROlJ ril^uTffiS?^ ** in c S nv ? otional memotv « in extended memory. After 
we rom image is loaded in memory device programming begins. 

For each block of the flash ROM to be programmed: 

1) BeginFlashO is called in PLATFORM.DLL 

?) P« Foper flash algorithm in PHLASHNT.EXE is executed. 

3) EndflashO is called in PLATFORMDLL. 

This process is repeated for each flash block specified in PLATFORMDLL. This allows 
for multiple devices on a single platform, multiple blocks within a device and block 
dependent iraual^uon/tenmnation code for each block. This also allows for automatic 
saving and restoring of memory regions such as boot blocks. 

During flashing, progress information is presented to the user: 

1) If production mode is not selected, an appropriate message window will be 
displayed on the screen, which will include tune of day, gas gauce style prowess 
indicator and status line message. 

2) Approximately once every second a short beep is sounded. 

3) At the start and completion of each step an appropriate code is sent to the 
debug port 

Video will be updated at least once every second. The sound will be generated 
approximately every second. Note that in production environment progress update can be 
disabled. 

After flashing is complete, DisableFlashO is executed from the PLATFORM.DLL file. 
One of two distinct sounds will be generated to indicate success or failure of the flash 
process. If video is available, an appropriate message window will be displayed. After a 
short pause system is re-booted. 

2.3 Completion Codes 

Although the program will proceed through many steps and will be capable of reporting 
to the user status at each step, only three major stages are identified by sound and 
keyboard LED codes. The three major stages are: 

1) Read and verify PLATFORMDLL file 

2) Perform platform specific initialization 

3) Program the part 
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If the program fails to complete any of the three major stages of the flashing process, 
program will use distinct sound sequence and keyboard LED* to inform user at which 
stage the program failed. At the start of the program CAPS LOCK, NUM LOCK and 
SCROLL_LOCK LEDs on the keyboard will be turned on. "The failure afeach of the 
three stages is indicated as follows: 

Sound Keyboard Description 



low buzz + 3 short tones CAPS, NUM, SCROLL 1 . Before reading platform.dll 



Stage 1 • Failure occurred before locating PLATFORM.DLL- Most likely due to errors 
in PLATFORM.DLL file format System is in stable mode, no changes have been made 
to the BIOS, no re-boot is needed. 

Stage 2 - Failure during platform dependent initialization. System is unstable and re-boot 
is needed. No changes have been made to the BIOS. 

Stage 3 - Failure during programming of the flash memory. System is unstable and the 
BIOS flash memory is corrupted. System must be restarted with Crisis Diskette. 

The program will also perform error detection at each of the steps. Unless explicitly 
disabled by the PRODUCTION option, as the program progresses it will report on the 
screen and debug port either the step number of the step currently in progress, or one of 
the error codes. Code numbers for errors and program steps are further defined in 
Appendix B2: 

When an error is detected before any changes are made to the flash memory part, then 
program will attempt to notify the user and then will exit PHLASHNT with proper error 
messages. Once the flash memory has been modified, errors will cause the program to 
halt 



2.4 Device Dependent Modules 

For each type of flash memory supported, there will be a part specific module to perform 
the following: 

1 ) Identify the part and return the manufacturer ID and the part ID 

2) Zero a range of flash memory (set all bits to 0) 

3) Erase a range of flash memory (set all bits to 1) 

4) Program a range of flash memory 



LEDs ON 



low buzz + 2 short tones 
low buzz + 1 short tone 
1 long tone 



CAPS, NUM 
NUM 



none 
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2.4.1 Autodatactlon 

In this module will be the code necessary to read the Manufacturer ID and part ID from 
the flash memory part If IDs cannot be determined, zero is returned* The built-in auto- 
detect module will not be used when the AutoSenscQ function is provided in the 
PLATFORMDLL file; the provided AuioSenseQ function will be used instead. 



2.4.2 Zero 

There are several part types which require that the flash memory is set to zero before it 
can be programmed. In this module will be the code necessary to set memory range to 
zeros. 



2.4.3 Erase 

Most flash memory parts require that the flash memory is set to all ones before the part 
can be programmed These parts often allow erasure of a full block of flash memory 
with a single write operation. In this module will be the code necessary to set memory 
range to ones. 

When block descriptors are defined in the PLATFORMDLL file, descriptors must be set 
up so that there is at least one descriptor for each "erasable" block in the flash memory. 
For example in Intel 28F004 flash memory there is one 16kByte BOOT block, two 
8kByte PARAMETER blocks, one 96kByte MAIN block and three 128kByte 
EXTENDED blocks. Each of die seven blocks can be erased with a single write and 
there must be at least one descriptor for each of the seven blocks. 



2.4.4 Program 

In this module will be the code necessary to read the data bytes form the BIOS ROM 
image and program these into the flash part. 



2.5 Supported Devices 

Initial set of flash memory devices supported by PHLASHNT.EXE will include the parts 
listed in the table below. For each part type a manufacturer and part ID and part 
description is listed. As new parts become available it may be necessary to add additional 
modules to PHLASHNT JsXE so that a new type of flashing algorithm is provided ( new 
AutoDetectQ, ZeroQ, ErnseO and ProgramO functions). If it is possible for the new part 
to use one of the existing algorithms and only the Manufacturer or Part ID changes, then 
this can be indicated in the FLATFORM.DLL file and no modification of 
PHLASHNT.EXE is needed (see section on PartTypes for more detail). 



Type 


MfgID 


Part ID 


Description 


2 


0x01 


OxAl 


AMD 28F256 


2 


0x01 


0x25 


AMD28F512 


1 


0x01 


0xA7 


AMD 28F010 


1 


0x01 


0xA2 


AMD28F010A 


2 


0x01 • 


0x2A 


AMD28F020 
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5 


UXU1 


A^AA 

0X29 




UXU1 


AuAA 

0x20 




vXUl 


Au A J 

0xA4 




0x0 1 


0x51 


1 A 

10 


0x01 


OxBO 


10 


A~ .A 4 

0x01 


0x34 


10 


0x01 


OxDC 


10 


0x01 


0x5D 


3 


A»* t T" 

Oxlr 


0xD5 


5 


A u 1 ^ 

OxlF 


OxDA 




Awl t 

Oxlr 


0x35 


1 
1 


Awl O 

oxic 


OxDO 


i 
1 


0X89 


0xB9 


i 
I 


0x89 


0xB8 


1 


A^. ft A 

0x89 


a n j 

0xB4 


1 


0x89 


OxBD 


A 


0x89 


0x94 


4 


A.. A A 

0x89 


. 0x95 


4 


0x89 


0x7C 


4 


A- .AM 

0x89 


0x7D 


4 


0x89 


A_ «* ^ 

0x74 


4 


0x89 


0x75 


4 


A_ A A 

0x89 


0x78 


4 


0x89 


0x79 


4 


0x89 


0x70 


4 


0x89 


0x71 


5 


OxBF 


A AM 

0x07 


12 


OxBF 


0x10 


5 


OxBF 


0x5D 


6 


OxBF 


0x04 


1 


0x20 


0x07 


7 


0xC2 


0x11 


11 


0xC2 


0x2A 



AMD28F020A 
AMD29F010 ~. 
AMD29F040 
AMD29F200T 
AMD 29F002T 
AMD29F002B 
AMD 29F002BXT 
AMD 29F002BXB 
ATMEL29C010 
ATMEL 29C020 
ATMEL29LV010 
Mitsubishi 28F101 
Intel 28F256 
Intel 28F512 
Intel 28F010 
Intel 28F020 
Intel 28F001 BX-T 
Intel 28F001 BX-B 
Intel 28F002 BX-T 
Intel 28F002BX-B 
Intel 28F200BX-T 
Intel 28F200 BX-B 
Intel 28F004BX-T 
Intel 28F004 BX-B 
Intel 28F400BX-T 
Intel- 28F400BX-B 
SST29EE010/29LE010 
SST29EE020 
SST29EE512 
SST 28SF040 
ST M28F101 
MX28F1000 
MX28F2000 
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3.0 PLATFORM.DLL Detail 

This module contains all platform dependent code and parameters needed to program a 
flash device on a particular platform. 



3.1 FHe Format 



PLATFORM.DLL is a Windows DLL that is produced by compiling PLATFORM.CPP 
(using Microsoft Visual C++ 42 or later). It contains specific platform data and 
executable code. A sample source code of the PLATFORM.CPP file is included in 
Appendix B3. 

File version for PLATFORMDLL will start with version "NT LOO". Versions are 
specified in the szVersion variable contained in PLATFORM .DLL. 



3.2 File Header Format 



The PLAT70RM,DLL file will have the format described below: 
// Global Variable Declarations 



DWORD dwFileSize // 

BYTE bManufactID // 

BYTE bPartID // 

DWORD dwFlags // 

DWORD dwljtvageBuf // 

DWORD dwMfglDAddr // 

DWORD dwPartlDAddr // 

BYTE bRetryCount // 

char «versionU // 

char srROMFileNamen // 

DWORD dwDLLFuncDefine // 

BYTE bblockTableSite // 



ROM iaage flla sixe 
Manufacturer of flash da vice 
Part ID of flash device 
Option flags 

Linear address of image buffer 

Linear address of mfg ZD 

Linear address of part ID 

Count for /Rn option (default « 0) 

PLATFORM.DLL version 

Na»e of BIOS image file 

Indicates what functions are defined 



number of blocks in biockTable 
BLOCK_DESCRJPTOR blocWableU 

BYTE ~ bpartTypesSiae // nunber of flash parts to add 
DEVICETABLE partTypes[J 



dwFileSize 
bManufactID 
bF&rtXD 
dwFlags 



Number of bytes in the BIOS-ROM file. 
Manufacturer ID 
Part ID 

Option flags. Must be combination of the following values: 



FLAG AUTOSENSEOFF 
FLAG~BACKUP 
FLAG~ttEWB10SONLY 
FLAG~PRODUCTION 



Don't read ID from the part 
Backup system BIOS ROM 
Don't flash if 64k at F000;0 same 
Max speed (sound Sl video off) 
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dwImageBuf 



dwMfglDAddr 
dwPartlDAddr 



bRetryCount 

szVersion 

szROMFHeName 

dvDLLFuneD*fJ.n« 

bblockTabl«8is« 
dwBlockTable 

bparttypesfiizo 
dwPartTypes 



FLAG SILENT 
FLAG" VERIFY 
FLAG~PLATFORMCMD 
FLAG BIOSPARTNUM 
FLAG'CHECKSUM 
FLAG CMOS 
FLAG"EMAGESIZE 



Do not generate any sounds 

Verify each block after flash 

PLATFORM option str present 

Flash only same BIOS pan number 

Checksum BIOS.ROM 

Clear CMOS checksum 

Verify image size matches flash part 



Address for BIOS.ROM image buffer in extended memory. This 
field determines the linear address of a buffer where the image will 
be read into. 

This area is also used when the SAVE option is specified. Any 
blocks to be saved will be using the address range starting at the 
address dwImageBuffer + dwFileSize. 

These two optional fields contain the linear addresses for the flash 
memory ID bytes. When these fields are zero, the default 
addresses of EOOOOh and EOOOlh will be used. 

Number of times to retry if flashing fails. 

Version of PLATFORM.DLL 

Reserved must be the string "BIOS.ROM*'. This field is used to 
identify and verify format of the PLATFORM.DLL file. 

Indicates what platform-specific functions are defined in 
PLATFORM.DLL 

number of blocks described in blocleTable 

Flash parts are programmed one contiguous block at a time. Each 
block to be programmed must have a corresponding block 
descriptor. 

number of flash parts to add 

Optional table of supported flash parts. Each entry in the table has 
the following format: 



typedef struct 

{ 

BYTE cMfgID; 
BYTE ePartZO; 
WORD wFlashType; 
char sxPartNaae 128] ; 
) DEVICCTABIX; 



// Manufacturer ID 
// Part ID 

// Flash algorithm type 
// Optional description 



The device table is terminated by a descriptor with cMfgID, 
cPartID and wFlashType set to zero. 
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procEnable 

procDisable 

procBegin 

procEod 

procGetBlock 

procCmdLine 

procSense 

prochFlashable 

procReboot 

procCheckSum 



Many platforms allow the same BIOS.ROM image to be used with 
several different flash parts. This table is used when a new part 
becomes available, the part is not among -the parts currently 
supported by PHLASHNT.EXE and the part uses the same 
flashing algorithms as one of the supported parts. 

enable flashing proc 
disable flashing proc 
begin flashing proc 
end flashing proc 

get next BIOS block for backup proc 
process custom command line options proc 
custom autosense proc 

custom OEM proc to determine if ok to proceed 
custom reboot proc 

custom checksum proc to be used if the BIOS ROM image 
checksum is not zero 



A sample source code for PLATFORMDLL file is shown in Appendix B3. 
3.3 Block Table Format 

Block table consists of a list of block descriptors. Each block descriptor in the block 
table is defined by the following structure: 



typedef struct 
{ 



DWORD dwBlockSize; // 

DWORD dvFileOffaet; // 
DWORD dwLinearAddress; // 

BYTE cMfgID; // 

BYTE cPartID; // 

WORD wBlockAttr; // 
) BLOCK DESCRIPTOR; 



Number of bytes in the block 
Of fact within BIOS.ROM file 
Linear 32-bit address of flash ROM 
Manufacturer ID or zero 
Part ID or zero 
Block attributes 



The block table is terminated by a descriptor with all entries set to zero. 



dwBlockSize 

dwFUeOfTset 

dwLinearAddress 

cMfglD 

cPartID 

wBlockAttr 



Block Size in bytes. Blocks must be contiguous. 

Offset of this block within the BIOS.ROM file. 

Starting address of this block in 32-bit address space 

Manufacturer ID or zero to auto-sense. 

Part ID or zero to auto-sense. 

Determines actions to be taken for this block. 

combination of the following flags: 



Must be a 



ATTR ZERO 
ATTR'ERASE 
ATTR SAVE 
ATTR'PROG 
ATTR~R£STORE 



Block must be zeroed before programming 
Block must be erased before programming 
Save content of this block before prog. 
Program this block 

Restore content of this block after prog. 
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Only one of ATTR^SAVE, ATTR.PROG, ATTR_R£STOR£ can 
be used at a tune. If no attribute Is specified, then 
PHLASHNT.EXE leaves the block unchanged. However, even if 
all of these are omitted, procedures BeginFlashO and EndFlashO 
are still called. BeeinFlashQ and EndFlashO can be used when 
two blocks are In different flash devices, or when a boot block 
requires additional functions to enable the block for write and to 
disable it before next block is programmed. BeginFlashO can also 
be used for conditional block processing. If BeginFlashO returns 
nonzero, the current block is not processed. 

Each ATTR SAVE block must be followed by an 
ATTR RESTORE block before another ATTR.SAVE block can 
beusel. 

Note that for a given flash memory range there may be several 
block descriptors. For example to preserve a 16k flash memory 
Boot Block in 64k erasable flash memory block, three block 
descriptors would be used. First descriptor to save the 1 6k boot 
block, second to erase and program 64k and third to restore the 
boot block. 

To re duce the time required for flashing, it is recommended that 
the ATTR.ZERO flag is not used, because this will avoid the 
zeroing step and cut the flashing time in half. Only few of the 
older flash memory types suggested that part is zeroed before it is 
re-programmed. Most parts do not require this operation. 



3.3.3 Multiple Flash Blocks 

The block table will be used to support multiple device flashing and multiple blocks 
within each device. For such platforms the ROM image file must contain the images for 
all flash parts to be programmed and the Block Table must contain proper offsets and 
lengths for each block ofdata to be flashed. 

To properly configure the platform before and after each flash block, PHLASHNT.EXE 
will call function BeginFlash(BlockJndex) to allow PLATFORM.DLL to perform any 
such set-up. It is the responsibility "of BeginFlashO & EndFlashO functions to perform 
any initialization or termination between blocks as needed. 



3.3.4 Processing Boot Blocks and ESCD storage 

« 

To program a memory range in the flash memory, there may have to be several different 
block descriptors, for the same memory range. This may be needed to preserve boot 
block or ESCD storage within a single 'erase' memory range. 

Many flash parts are erased by a small number of write operations, one for each memory 
block. For example Intel 28F400 flash memory has seven blocks (one 16k boot block, 
two 8k parameter blocks, one 64k main block and three 128k extended blocks). This part 
can be erased with only seven write operations. 
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For other parts, erase function may erase 64k of flash memory at a time* regardless of 
division of this range into boot and parameter blocks. In such cases it is important that 
there are three block descriptors for such a 64k rtnge of memoty. The first block 
descriptor in the table is used to save boot block, second block descriptor to erase and 
program the parameter blocks and the third descriptor to restore the boot block in this 
range. 

Some parts require that a additional platform dependent actions need to be taken before a 
boot block can be programmed. For example Intel parts require that VHH voltage, in 
addition to VPP voltage, is properly set In such cases block descriptor must also have 
such a functions in BeginFTashQ and EndFlashO procedures (called before and after 
each block). 



3.3.5 Block Table Examples 

The code in the following examples would be placed in the "blockTable" section of 
PLATFORM.CPP. 

Erase a 4KB block at FC000. 

DO 4 * 1024 ; 4» 

DO 0 ; nit off jet 

DO OOOrCOOOh I tinea* eddreaa of thia block 

OB 0 ; Mtg ID (0 - default) 

OB 0 ; tart 2D (0 • default) 

DW att*_£MS£ $ Action tUqs 

Zero, then program a 128KB block at E0000 on the specified part 

DO 121 * 1024 ; 121KB 

DO 0 ; rut offeat 

OD OOOEOOOOh ; Linear addxeae of thia block 

08 Olh ; Kf9 ZD (0 - default) 

OB 2 Oh ; Fart ID (0 - default) 

Dtf ATT* ZZZO OK ATTK_FROG ; Actios flags 



3.4 PLATFORM.DLL Functions 

Currently supported functions are; 

The following functions contained in PLATFORM.DLL are accessed by 
PHLASHNT.EXE to implement platform-dependent functionality: 

EnableFIash 

DisableFlash 

BeginFlash 

EndFlash 

GetBlock 

CmdLine 

AutoSense 

IsFlashablc 

Reboot 

Checksum 
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The following functions allow PHLASHNT.EXE to access global variables 
and data structures contained In PLATFORM.DLL: - s ■ 

GetBIOSFileSize 

GctManufactID 

OetPartID 

GetFlags 

GetlmagcBuf 

GctMfglDAddr 

GetPartlDAddr 

GctRctryCount 

GetblockTableSize 

GetpartTypesSizc 

GctBlockTablc 

GetpartTypes 

GetDLLVenion 

GetROMFileName 

GetDLLFuncDefine 



3.4.1 Function EnabJeF!aah() 

Entry: None 

Returns: Error code (or zero) 

This function must be present in the PLATFORM J3LL. It is called before any attempt to 
access the flash memory. Actions typically performed by this function include: 

Map flash device into memory 

Disable Cache, Shadowing and Power management 

Flush Cache 

Disable PC! bridge 

Enable ROM for write (VPP on) 

Most platforms require that a jumper is changed before the pan can be enabled for 
flashing. EnableFlashO procedure must verify that this jumper has been removed and 
return an error code if it was determined that jumper settings are incorrect. See Appendix 
B for error codes. 

3.4.2 Function DisableFlashO 

Entry: None 

Returns : Error code (or zero) 

This optional function is called after the last block has been programmed (or error was 
detected). It will be called immediately before PHLASHNT.EXE exits (typically as a last 
call before re-boot). It should perform all functions necessary to be able to cleanlv re- 
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Action typically performed by this function include: 
Disable ROM Write (VPP oft) 



3.4.3 Function BeglnFlaah(DWORD Blockjndex) 

Entry: Index of the block about to be programmed (or zero if table not used) 

Exit: None 

Returns: Error code (or zero) 

This optional function is called by PHLASHNT.EXE immediately before the flash block 
is processed. It will be called for each block (found in the block table). 

Actions typically performed by this function include: 

Save BOOT block before it is erased 

Switch from one device to another (on platforms with multiple devices) 
Enable VHH for boot block re-program 
Determine if the current block should be processed 

If BeginFlashQ returns nonzero, the current block will not be processed. 



3.4.4 Function EndFlash(DWORD Blockjndex) 

Entry: Index of the block just programmed (or zero of table not used) 
Returns: Error code (or zero) 

This optional function is called by PHLASHNT.EXE immediately after the flash block 
was processed. It will be called for each block (found in the block table). 

Actions typically performed by this function include: 

Restore BOOT block saved by BeginFlashQ function 
Clean-up between programming two different devices 
Disable VHH if boot block was just programmed 

3.4.5 Function GetBlock(DWORD Index, DWORD BufTer_Address) 

Entry: Index of the block to be copied and linear address of a 64k buffer 

Exit: Buffer is filled with the next block of existing BIOS ROM image 

Returns: Negative error code, zero, or positive block index 
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This optional function is called by PHLASHNT.EXE whenever the /BACKUP flag is 
specified. OetBlockO is used to assist when saving the existing content of the flash 
memory before the flash memory is changed. Because many BIOS images are de- 
compressed into shadow RAM, it is not always possible for PHLASHNT.EXE to access 
all of the BIOS ROM image without platform dependent system setup. Function 
GetBlockO is necessary to allow for platform dependent accessing of the existing BIOS 
ROM image. BIOS ROM image is saved by PHLASHNT.EXE using the following 
steps: 

1) Call GetBlockflndex, Buffer) with Index set to 0 and the 64k buffer, pointed to 
by the parameter Buffer, filled with a pre-defined pattern If the partem in the 
buffer is not changed, program exits with error. If the pattern is changed, then the 
buffer is saved as the first 64k block in the BIOSJJAK. file, then program proceed 
to next step. 

2) Call GetBlock(Index, Buffer) with Index set to the value returned by the 
previous call to GetBlockO. ttve tte buffer int0 B10S.BAK and repeat this 
until the value returned by GetBlockO is * non-positive number. 

3) If the last value returned by GetBlockO is zero, then proceed with flashing of 
the memory. If the last value returned is negative error code, report the error, 
delete BIOS3AK and exit 

It is the responsibility of the GetBlockO implementation to ensure that the platform is in a 
proper state to allow the GetBlockO to copy BIOS ROM image into the buffer and that 
the platform is restored to the original mode before GetBlockO returns control to 
PHLASHNT.EXE. In particular, GetBlockO « befo" » "J 1 » l ntAt t0 

EnableFlashO. The buffer pointer passed to GetBlockO is always m the real memory 
range below 640k, to allow direct transfer to disk. 

3.4.6 Function CmdLlne{char far *azOptiona) 

Entry: Pointer to a string with the platform specific command line options 

Returns: Error code (or zero) 

This optional function is called by PHLASHNT.EXE immediately, after the 
PLATFORM.DLL was read in. It is passed the address of the string containing all toe 
platform specific command line parameters (specified after the equal sign with 
/PLATFORM*"...** command line option). The string includes the leading and trailing 
double quotes, if any. 

3.4.7 Function AutoSenseQ 

Entry: Manufacturer and device IDs retrieved from PLATFORM.INI header 

Returns: New ID retrieved from the flash part (or zero) 
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This function is called by PHLASHNT.EXE immediately after EnableFlashO function in 
the PLaTFORM.DLL was called. The AutoSenseO function enables aulo detection of 
memory flash parts when "non-standard" memory organization is used for the flash 
memory. For example when two separate parts are used for even and odd BIOS 
addresses (in which case the conventional auto detect mechanism will fail), this function 
can be used to obtain and verify ID for each of the parts. 

IDs are one byte long and are packed into a DWORD, with manufacturer ID in BYTE 0 
and device ID in BYTE 1. 



3.4.8 Function lsF!ashable(char far *szErTorMtg) 

Entry: Pointer to string to contain returned error message . 

Exit: azErrorMsg containing error message string. 

Returns: Error code (or zero) 

This optional function is called before EnableFlashQ to determine if it is ok to proceed. 
If the function returns a nonzero error code, the string azErrorMsg is displayed and the 
program terminates. Up to 254 bytes plus a terminating NULL may be returned in 
szErrorMsg. 

An example of how this might be used is: for the same platform, an OEM sells a system 
with and without Plug and Play capabilities. The IsFlasnableQ function can determine if 
the system currently has Plug and Play and will not flash a Plug and Play BIOS on a 
platform that doesn't already have it 



3.4.9 Function RebootQ 

Entry: None. 
Returns: None. 

This optional function is called after programming is complete to reset the system. If 
provided, this is called instead of PHLASHNTs own reboot code. 



3.4.10 Function CheckSumQ 

Entry: None. 

Returns: Error code (or zero) 

This optional function is called before programming to determine if the checksum of the 
BIOS ROM image is correct Normally, the BIOS ROM image checksum for a NuBIOS 
image is zero. This routine may be used to provide an alternative checksum verification 
method when it is known that the ROM image checksum will not be zero, if this function 
returns non-zero, PHLASHNT will terminate. 



. 3.4.11 Function GttBlOSFHeSlzeO 

Entry: None. 

Returns: Size of BIOS image 
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This function returns the contents of the global variable uNvFileSize from 
PLATFORM.DLL. 



3.4.12 Function GetManufactJD{) 

Entry: None. 
Returns: Manufacturer ID 

This function returns the contents of the global variable bManuf&ctID from 
PLATFORM.DLL. 



3.4.13 Function GetPartlDQ 

Entry: None. 
Returns: Part ID 

This function returns the contents of the global variable bPartID from PLATFORM.DLL. 



3.4.14 Function GetFlagsO 

Entry: None. 
Returns: option flags 

This function returns the contents of the global variable dwFlags from 
PLATFORM.DLL. 



3.4.15 Function G©tlmageBuf() 

Entry: None. 

Returns: Location of Image BufEfer 

This function returns the contents of the global variable dwImageBuf from 
PLATFORM.DLL. 



3.4.16 Function GetMfglDAddrfl 

"Entry: None. 
Returns: Address where Manufacturer ID is located 

This function returns the contents of the global variable dwMfglDAddx from 
PLATFORM.DLL. 
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3.4.17 Function GetPartiDAddrO : 
Entry: None. 

Returns: Address where Part ID is located 

* 

This function returns the contents of the global variable dwPartlDAddr trom 
PLATFORM.DLL. 



3.4.18 Function GetRetryCountQ 

Entry: None. 

Returns : Number of times to retry flashing if failure occurs 

This function returns the contents of the global variable bRetryCount trom 
PLATFORM.DLL. 



3.4.19 Function GetblockTableSfce() 

Entry: None. 

Returns: Number of blocks in blockTable 

This function returns the contents of the global variable bblockTableSize from 
PLATFORMDLL. 



3.4.20 Function GetpartTypesSlztO 
Entry: None. 

Returns: Number of additional flash parts thai PLATFORM.DLL will describe 

This function returns the contents of the global variable bpartTypesSize from 
PLATFORM .DLL. 



3.4.21 Function GatBIockTablaQ 

Entry: None. 

Returns: address of blockTable 

This function returns the address of the global structure blockTable from 
PLATFORMDLL. 
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3.4.22 Function GetpartTypttQ 

Entry: None. 

Returns: address of partTypes 

This function returns the address of the global structure partTypes from 
PLATFORMDLL, 



3.4.23 Function GetOLLVersionO 
Entry: None. 

Returns: Version of PLATFORMDLL 

This function returns the contents of the global variable szVersion from 
PLATFORMDLL. 



3.4.24 Function GetROMFlleNameQ 

Entry: None. 

Returns: Name of BIOS ROM file 

This function returns the contents of the global variable szROMFileName from 
PLATFORM.DLL. 



3.4.25 Function GetDLLFuneD«flneQ 

Entry: None. 

Returns: Indicates what platform-dependent functions are defined 
in PLATFORM-DLL 

This function returns the contents of the global variable dwDLLFuncDefine from 
PLATFORM.DLL. 
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4.0 BIOS. ROM Detail 

The ROM image file size must be large enough to contain all blocks in the flash device(s) 
to be programmed. Any required post-processing of the BIOS image, such as boot block 
swapping or data compression, must be already incorporated into the ROM image file 
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5.0 Genera! Implementation Guidelines 

Programs will be developed using Microsoft Visual C-H-, V42 or later? 

Because it is expected that this program will evolve as new devices become available and 
because code sire is not critical, the style of coding should be such that code readability 
and clarity should have higher priority than executable code compactness. 

However, because the program may also be used is production environments, It should be 
structured as to allow shortest possible time for part flashing. In particular, it should have 
a mode where non-critical user interfaee notifications can be disabled; and whenever 
possible, time consuming flashing functions should be written in optimized assembly 
language. ' 



28 



PhoenfrPHLASH • PI— h ROM Programming Utntty for Window NT Dwlgn Specification 



AppendlxBI -Future enhancements 



Completion Codes with Keyboard LEDs 

If the program fails to complete any of the three major stages of the flashing process, 
program will use keyboard LEDs to inform user at which stage the program failed. At the 
stan of the program CAPSJLOCK, NUM.LOCK and SCROLL.LOCK LEDs on the 
keyboard will be tuned on. The failure at each of the three stages is indicated as follows: 

Keyboard Description 
LEDs ON 

CAPS, NUM, SCROLL Before reading platform-dU 

CAPS, NUM Before platform init 

NUM After platform init 

none Successful completion 
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Appendix B2-PHLASHNT.H Completion and error codes 

FFh Memory alloc for BIOS.BAK buffer failed 

FEh BIOS .B AK already exists (rename or delete it) 

FDb File Create failed on BIOS.BAK 

FCh File Write ftled on BIOS.BAK 

FBb File Dose failed on B10S.BAK 

FAh BIOS backup sot supported in PLATFORM .DLL 

F9h File Open failed on PLATFORMDLL 

F8h File Read faOed on PLATFORMDLL 

F7h FUe Close Sailed on PLATFORMDLL 

F6h Failed to locate signature bytes in PLATFORMDLL 

F5h Unsupported PLATFORMDLL file version 

F2h Device table in PLATFORMDLL bas too many entries 

F 1 h Device table b PLATFORMDLL bas unsupported flash type 

FOh Combined SAVE or RESTORE attributes in PLATFORMDLL 

EFh SAVE block without matching RESTORE block in PLATFORMDLL 

ECh Part ID not found in table of supported parts 

EBh PLATFORMDLL found errors in command line parameters 

EAh Alloc for BIOS ROM image failed 

E9h Open failed on BIOS ROM image file 

ESh Read failed on BIOS ROM image file 

E6h FUe Close failed on BIOS .ROM 

E4h Attempt to read flash memory ID failed 

E3h PLATFORMDLL failed to return flash memory ID 

E2h Could not find BCPS YS block in BIOS ROM file image 

E 1 h File does not contain the same BIOS part number 

EOh File does not contain different version of BIOS ROM image 

DFh Data written to flash does not match BIOS ROM image 

DEh Write to flash memory failed 

DDh Erase flash memory block failed 

DCh VPP is not at expected level 

DBh Erase sequence failed 

DAh New DMI string is too large 

D9h The BIOS ROM file may not be used with this system 

D8h Alloc for DM3 OEM string Med 

D7h No space for the specified DMI OEM string in the BIOS ROM 

D6h DMI OEM strings not supported (BCPDMI 0. 1 + required) 

D5h Could not find BCPDMI block in BIOS ROM file image 

D3h BIOS ROM file may be corrupt (checksum not zero) 

D2h BIOS ROM file size doesnt match flash part size 

D 1 h DMI system and chassis strings require BCPDMI 2.1+ 
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Appendix B3-PLATF0RM.DLL Sample source code 



PLATFORM.CPP 



♦ TITLE fUTFORH.Cf* - 32~Blt DLL to provide platforx dependent functionality 

* to >kuukkt.exe 

* Copyright (c) 199? by Fhoenix Technologies, Ltd., All Rights JU»trr*d. 

• »hoenix Technologies Ltd. CCHriMNTIAL* 



* rilenaae: 



rLAtroKM.cpr 



Proj.ctt SMLXSBNT.BCS 
Functional Blocxt 

Ccmtnte: Ac variable dwDLiruncDefine Is ased la 9KLASKXT to determine 
what platform specific fuaetiooe la FIATfORH.DLL have been 
defined. Listed below art the possible values of 
dvDLLruneDefine end what functions they indicate ere defined 
in this moduli: 



Oil CMAftttrLUH 
Dil^OISXILm-UK 
DLL^ItGXMTASH 
DLL tHDFULS* 
DLL GtTlLOCX 

duTchdliw 

DLL XOTOSCWSt 
DLL^ISriASHAlLT 
DLL WSO0T 
DUTCKTCXSUM 



c&ej»ieriss& 

DisebleFissh 

legiariash 

•etilock 

Cx*Line 

JfcuteSense 

zsrlaihebie 

Reboot 

ChecfcSutt 



Contents ; 



* version Control Information; 
* 



• SLog: X; /nto/«rchiT^/nutool*/phl*»h.nt/it»9«2 /driver */pl*tfor».cpv S 

• Rev 1.0 

• Initial cavitiea. 



linelude ~stdafx,h" 
♦include <afxdllx.h> 

linelude <etdie.h> 

fl include •0:\KUT0OLS\PKLX$a *»T\$TACt2\phlaehnt.h - 
ftdefine PLATFORM CM 



jj ~ , „ ■ 

// Global variable Declarations 



WOW) dwFileSiae 
IYTE bHanufeetZD 
arrr. bPartlD 



• 0x00040000/ // *OH iM9e tile site 

* 0x19; // Manufacturer of flash device 
- 0x*Oi // tart ZD of flaeb device 



// Option fl»g» 

DWORD dwrieos* FXAC_B103FARTHUM I FlAS_CKtCKS?K I STAC iKAGtSIZT; 
D«fORD dwXmagasuf « 0x00200000; // Linear address of laage buffer 
DWORD dwHfgXDAMr - OxJTTXOOOO; // Linear address ef afg ID 
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DWORD 

im 

char 
Chir 



DWORD 



dvpartiCAddr 
bBttryCount 
atVaralonH 
StRCHfUaHao, 



• Oxrmoooi; // Linaor addraas of pATt to 
■ 0; /; Count for /ta option fdafault - 0) 

• nrr i.oo*/ // rukTro*x.ou, *aruon - 

[] - *B2QS.BOH*/ // tfas* of BIOS iauos fiU 



// Indicatai 
dwDLLruncDafina m 



what fuaetieaa ata dtfinod in PLATfOBM. DLL 
DLL SKXAUTXASK | 
DLL~DIiABLirLUH 
DLL^UttlHTLXSH 
DLL*EHCrULS8 

dll~ox?blocx 
dlljwtosw5i 

D£JL M ZSfLXStaiXX i 
DLL bxsoot I 
DUTciXCtSW ; 



BYTE bblockTablaSiio 
BLOCK_DEaCRIPTQR bl©ckTablt(J 



// 
// 
• 5# 



dafina blocxTabXo 



// ftuabtr of blocks in blockTablt 



1024, 



128 

0, 

OxFFIXDOOO, 

0, 

0, 

ATTB Z£RO 



// 121KB (Low) 

// ma off««t 

// Lintar addrass of flash Mh 
// KfoXD (iiai os 4o fault ) 
// PartID (sane as dafaultj 



( 

121 • 1024, 

0x00020000, 

OxlTFEOOOO, 

0. 

0, 

ATTR_X*gO 



// 121KB <ii«t» 
// Fila offset 

// Linear address of flash BOW 
// KfgiD tiAM as da fault) 
// PartID (iam as default) 



1024, 



( 

12i 

0, 

oxrrnoooo, 

o, 

o, 

ATTB ZMSt 



// iatn (Low) 

// rile oftsot 

// Linear oddress of flash BOM 
// HfgID (sane as da fault) 
// PartID (saaa as da f salt) 



( 



1021, 



121 

oxrnxoooo, 
xrm_rnc« 



// 12SU (Lew) 
// rile off sot 

// Linaar oddrsss of flash BOH 
// MfgID (i4M as da fault) 
// PartID (itat ss da fault) 



( 

12i * 1024. 
0x00020000, 

oxrrrtoooo, 

0, 
0, 

ATTB PROG 
), ~ 



// 121KB <Sie;h) 
// rile offsat 

// Linear addrass of flaah bom 
// ttfffXD (saae as da fault) 
// Parti© (aane as dt fault) 



0, 
0, 
0, 

o. 



// Weed to terminate blockTable with 
// a block sot to 0. 
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im bpartTyptsSltt - 1; 

DCV I C£TASI*t ptrtTyp«»[} ■ 

( 



< 

0x89, 
Ox»D, 

1, 
0, 

"Intel 281X20" 

), 

i 

0, 
0. 
0, 
0, 



// — 

// define perctypei 

// « 



// ouaber of flash parts on pletfora 
// Set to 0 if paxtTypet is not used! 



// Manufacturer 10 of flash device 
// Device 10 of flash device 
// Hashing algorithm typo 
// ichom wrertsite 
// nut of flash doTiee 



// Heed to texminats paxtTypes with 
// * block s«t to 0* 



EXX5TANCE 



aRetnei32 • 0; // HOTE: Do HOT change this line of code. 



functions 



* Function hum: DUNein 

* Description: 

* Perajftetexa: 

* lit turns: 



♦ Motes: 



do nor nooxrx this roncrxoti 



extern "C - int APXttfTftY 

DllMein (HINSTANCX hlnatance. tmow dvfceeaon, LPVOID lpfceserred) 



If (dwRttSon — DtX w yROC£5S w ATTAOi) 



) 



?*ACE0 ( - FLAT TOKi . OIL &eginf\n - >; 

h*eraei32 - LoedLibrary( •Ker»el32.Dli- >/ // Get Bandit to Ksrnti32. 011 



• 1st if (dwReasoo ■« DU,_P*OCOS_DrTACH) 



t 



> 



7MC£0<*PlJtTro«M.DU TerainetinglVn''); 
if (hKtrnel32) 

freeUbraryt hKemei32 1/ 



return 1; 
> // DllHelnO 



// ok 



• Function Hen 

• Description: 

• P*ra»*t«K«t 



InebleFlash 
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* Mtum: 

* Wotes: 

dll rtrwc Tyre void tnsbierietho 

< 

printf rtnAblerlsshNn*)* // (stub) 

) 

/•«.»••*•»•»••«••••«.•», •.»•»».»••.,, .... 

* runctioa Kami Dissbletteth 
* 

* Deecnptioni 

* Fu4ji«ttrii 

* Mturnsi 
* 

* Dotes: 

DU-_rttNC_TYPC void DistblerUsM) 

print* <*Dls*blerissh\n*)/ // <stub) 

I 

/ ..••«••.•...••••...•.•••...•••....•.•••••...•••••.«••. • 

« 

* runction Vtu: Se^inFlesh 
« 

* Description: 

* ft stums: 
♦ 

* Notes: 
* 

DLL ruvc TYPE short BeffinftsshC OSBOftT blocXNumber ) 

{ 

return Oi // (stub) 

* Function Kai: Endrlssh 
• 

* Description: 

* rsrweters: 

* Return*: 

* Hotel : 

DLL rvNC TT*T short tndttssM CSHOR? blocUtaber ) 

1 

return 0; // (stub) 

) 

* runction Nam: Getllock 

* Description: 

* f trimeters: 

* ft* turns: 

* Votes: 

•*..........»•... *•«••»•.«. •••»«..» a ..«»««»»*t .••»•••••••••••••••••••••••/ 

ou. nmc mt shoxt e«ttlock( sum dwmd*«, ruwwc tfwest > 
( ~ 
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print fCOttSlock: 4vXndtx,dvDst pessed ia-*d,%d\n\ dvtndex, avost )/ // (stub) 
return 0; 

) ::: 

* runction Msme: oaiLint 
* 

* Description: 

* fertreteis: 

* Retumi: 
• 

4 Kotes: 
♦ 

printf (*CadLine\n a ); // (stub) 
return ( 0 ); // (stub) 

* runction AutoStnse 
♦ 

* Dtserlptlon: 

* Ptruutirn 

* M turns; 
* 

* Metes: 

* Ths sanufecturer ID is in 1Y7£ 0 tad Uric* ID in lYTt 1 

OLLjrwCJTtTZ DWORD AutoSsnse* CHORD FertHfgJD ) 7 
return* 0x0000 )i // (stub) 

> 

* runction Kami: Xsrieshsble 

* Description: 

* Ptruutin: 

* Returns: 

* Kotcs: 

DLL rTOC TYPC QSHORT Isflssbsblt (} ' 

{ 

printf C*Ierieshsble\n* )/. // (stub) 
rsturn 0; 

) 

* 

* runction Vast: Reboot 

* Description; 

* Parameters: 

* Returns: 
* 

* notes: 

DLL ITJNC TYf t void Reboot*) ' 

( . 

printf ("Reboot \n") # // (stub) 

) 
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• runctioft Uimmt ChtckSua 

* D*«criptioni 

• P*r*a*ttr«; 

* lUturn*: 
* 



WLtjrsHcjrrtt void c**ct5u»n 

printf (*Ch»cklua\n*)i // Utub) 



// 
// 
// 

oll rune 
DuTruHc" 

DLL rwc" 

DuTroNc" 

DLlTrUHC - 
DLlTrOHC" 

oLiTruNC - 

DlxTnJNC* 

DLiTnroc* 
ou"rwc' 
ouTruNc" 



voTSt do mot Mooxrr the roNCfiom luted below. 



Mturafdvftlotiu); ) 
( r»tura<bMaauttctXD); ) 
( rotors* (bPartXD); ) 



.type dword c«tiiosrii«six«(void) ( 

TT*C im CfttHfcAUf ICCXD (VOid) 

.TYPE BYTE 0«tP«rtID<v©id) 
TYPE DWORD Gotf!*?* {void) 
.TYPE DWORD CotJ»*9«Buf (void) 
TYPE DWORD CotMfgXDXddr (void) 
TYPE DWORD CotP*rtIDAddt (void) 
TYPE IYTE GotRatryCouat(void) 
TYPE BYTE G«tbloefcT4bX«f ito fvoid) 

TYPE BYTE CvtpirtTyptsSitt (void) . 

TYPE BLCCR.DESCRIPTOR •OttBloekTofclo {void) ( ttturii (U>lockT*bl« 1 0] ) j ) 
.TYPE DEVXCETABLE *Cotp4rtTyp«» (void) i roturw UptrtTvpot 10) ) / ) 

TYPE ctur *GttDLLVerjioo(vi5id) ( rBtura(i*Vor»ioe) ; } 

TY?E char *G« t roh riitN4Bt (void) ( rot,uraU*RCHriXott«M) / } 

TYPE DWORD 6«tDLLruncDt fiae (void) ( «tura(dwOLLPuacDefin#) ; 1 



return (oVn*g«) * ) 
rttur&(dwlM9«Buf); ) 
rtturo{dW£9ZDMdr); > 
r«tum(dwMrxrDXddrJ ; ) 
roturn{bMtxyCou&t)/ } 
rtturafbblocmbltSltt); ) 
return fbpcrtTypotSitv)/ ) 
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This paper presents a proposal for a new BIOS service 
which will be known as the BIOS32 Service Directory. ' 
The new service will provide information about those 
services in the BIOS that are designed for callers running in 
a 32-bit code segment CThe BIOS32 Service Directory will 
itself be a 32-bit BIOS service.) Tne expected clients of mis 
service are 32-bit operating systems and 32-bit device 
drivers. The expected providers of this service are BIOS 
venders that implement one or more 32-bit BIOS services. 
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1 Introduction 

The BIOS32 Service Directory propool came into being during the attempt* to establish 
a 32-bit code interface for the Peripheral Component Interconnect (PCI) standard A 
major problem that needed solving was: How does a 32-bit caller determine the existence 
of a 32-bit BIOS service? The drawbacks of a functional interface (Lc, tn entry point that 
control is transferred to) are clear in the case where the functional interface is non-extant. 
A recoverable method would seem to entail a search for a signature as proof that a 
functional interface does exist In feet, one of the first BIOS 32-bit services, EISA, uses 
an existence signature at a fixed location in the OFOOOh segment However, as more 32- 
bit BIOS services are required and come into existence, it is obvious that providing a 
signature (and any associated information, such as entry points, segment requirements, 
etc.) for each is a costly usage of a scarce memory resource. Hence, the idea behind the 

The BIOS32 Service Directory uses a single signature to indicate the 
existence of a generic 32-bit service that returns information on all specific 
32-bit services 

A further justification for implementing a general solution versus continuing to solve the 
problem on a case-by-case basis is seen in the obvious benefits a standard provides to the 
industry. Code reusability, modular fplug-in'-able) implementation of new 32-bit BIOS 
interfaces, thorough specification of calling environment requirements, etc., are a few 
benefits which come to mind. 

The BIOS32 Service Directory has two components: the Header and the Calling Interface. 
The Header is a static data structure that includes the signature and which is located in a 
well-known memory range. The existence of a valid Header implies the existence of the 
Calling Interface and, in fact, describes its entry point The Calling Interface is a body of 
code and data which exists in a separate memory space apart from the Header and any 
particular 32-bit BIOS services. It provides a functional interface through which a caller 
receives information about a particular 32-bit BIOS service. (Section 0 describes a 
hypothetical memory map of the Header, Calling Interface, and the "XYZ" 32-bit BIOS 
service.) 

The design of the Calling Interface is extensible in two dimensions. First it is a function- 
based interface - future revisions of the service can incorporate new features, as they 
become necessary. Second, specific 32-bit BIOS services will be represented by a 4-byte 
Component ID. This will enable both OS callers and BIOS32 Service Directory 
implementors alike to easily add new 32-bit BIOS services as they become available. 
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Interface to the BIOS32 Service Directory, and a summary with <5?amp^ 



2 The BIOS32 Service Directory Header 

A BIOS which implements the B10S32 Service Directory must embed a specific, 
contiguous 16-byte pattern somewhere in the physical address range OEOOOOb - OFFFFFk 
The pattern must be paragraph aligned (Le M it must start on a 16-byte boundary). This 
pattern is known as the BIOS32 Service Directory Header. 

The Header is comprised of six distinct fields* The following table describes each field. 
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Offcet 



Size 



4 

bytes 



4 

bytes 



Description 



The ASCII signature "J2_\ This string is packed left to 
right offset 0 is 'J (underscore), offset 1 is *3\ offset 2 is 
T, offset 3 is another ' 



The entry point for the BIOS32 Service Directory Calling 
Interface. This is a 32-bit linear (Le, not segment-offset) 
physical address. 



8 
9 



1 byte 
1 byte 



The revision level of the B10S32 Service Directory 
Header and Calling Interface. The current revision is Oh. 

The length of the BIOS32 Service Directory Header. This 
is measured in units of paragraphs (16 bytes). The current 
Header has a length of lh. 



10 



1 byte 



Tbe BIOS32 Service Directory Header checksum. This is 
a value which makes the cumulative ADD value of all 
bytes in the Header equal to Oh. 



11 



5 

bytes 



This field is reserved and should be set to Oh. 



TABLE 1: The BIOS32 Service Directory Header 



*e TJl S l 2 S T* ce DilCCt0ty detenaiD * * by locating 

^W^T * ^ by SCannin8 0E0000h to OFFFFOh * P^graph increments and 
oobng for a signature match (■ J2J0 in the first 4 bytes of each pSgraph- When, and 

Heal L Sl n^ * C ^ ***** a *«ksum of all bytes m the 

fh^i? A Sn e , ? f * P"*"** is found at offset 9h.) AD bytes in the Header 

^ ^ a result of Oh. If the checksum is valid then the 32-bit entry 
If iLl »t T * me address for BIOS32 Servicc directory Calling Interface, 

platfo ^ DOt 11101 * e BI ° S32 SctVice Directory do « not exist on the 



02603. P002 



-3- 



Appendix C 



Standard BIOS 31»bit Serrlct Directory 



3 The BIOS32 Service Directory Calling Interface 

If the BIOS32 Service Directory existence has been determined (via the Header test, 
above) then the 32-bit physical address found in the Header can be used as the entry point 
to the Calling Interface. Clients should CALL FAR to this address. The clients calling 
environment has the following requirements. 



31 Code Segment 

The CS code segment selector must be set up with a segment descriptor with the 
following values: 

• The base address must be less than or equal to the (4kb) page address of 
the page that contains the entry point For example, if the entry point is 
0FFF81234h then the base address must be less than or equal to 
OFFFSlOOOh. 

• The limit must be such that the base address plus the limit generate an 
address that is greater than or equal to the last address on the (4kb) page 
which follows the page containing the entry point For example, if the 
entry point is 0FFF81234h then the base address plus the limit must be 
greater than or equal to 0FFF82FFFh. 

Simply stated, the base address and the limit must "encompass" both the 
page that contains the entry point and the following page. 

• The segment type must be 100b (code, execute only) or 101b (code, 
execute/read). However, the implemeators of the Service Directory cannot 
assume read access to the CS code segment 

The system bit must be 1 (nonsystem segment) . 

• It is recommended that the Descriptor Privilege Level (DPL) be 0. (The 
CS descriptor DPL becomes the Current Privilege Level, or CPL). If the 
CPL is not 0, then the OS must provide trapping and virtualization services 
for ring 0 privileged instructions (such as those that access CRx). Note 
also the dependency of this field on the IOPL field in EFLAGS (see Section 
0). 

The Default Size bit must be 1 (32 bits). 

The BIOS32 Service Directory entry point, and its associated code and data, may 
be located anywhere within the 4Gb physical address space. However, it is 
guaranteed to be physically contiguous (i.e.. it will be delivered in ROM or 
FLASH space) and to fit within two pages (U- it will not span three pages). 
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3 2 Data Segments 

The DS data segment selector must be set up with a segment descriptor with the 
following values: 

• The base address must be equal to the CS base address. 
The limit must be greater man or equal to the CS limit 

• The segment type must be 000b (data, read only) or 001 (data, read/write). 
However, the implementors of the Service Directory cannot assume write 
access to the DS data segment 

• The system bit must be 1 (nonsystem segment). 

• The Descriptor Privilege Level (DPL) must be greater than or equal to 
CPL (see the DPL field in Section 0). 

There are no requirements concerning the ES, FS, and GS data segment selectors. 



3.3 Stack Segment 

The SS stack segment selector must be set up with a segment descriptor with the 
following values: 

The segment type must be Ollb (data, read/write, expand-down) or 001b 
data, read/write, expand-up). 
The system bit must be 1 (nonsystem segment). 

The Descriptor Privilege Level (DPL) must be equal to the CPL (see the 
DPL field in Section 0). 
The Defeult Size bit must be 1 (32 bits). 
The Granularity bit must be 1 (4Kb). 

Note mat the above settings ensure a stack size of at least 4kb. It is the caller's 
responsibility to ensure mat there is at least lkb of unused stack available. 
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3 .4 Paging 

Paging may or may not be enabled. If paging is enabled, then the address space 
that is described by the CS and DS selectors must be linearly contiguous. That is, 
the original physical contiguity of the Calling Interface as found in ROM or 
FLASH must be preserved. (The Calling Interface code and data is written to be 
position-independent and HP-relative). 



3.5 IOPL 

In order for the Calling Interface to execute I/O instructions, the I/O Privilege 
Level (IOPL) field in EFLAGS must be greater than or equal to the CPL (see the 
DPL field in Section 0). 

The BIOS32 Service Directory Calling Interface is function-based and all parameters are 
passed in registers. If a register is not specified as an output parameter for a taction, 
then it will be preserved All flags are preserved Function values are passed as input 
parameters in register BL. Return status is passed back in register AL. A return status of 
OOh indicates that the function was successful- A return status of SOh in d ic ates that the 
requested function (in BL) is not supported Other AL return values are defined by the 
individual functions. There is currently one B10S32 Service Directory function defiled 
It is specified below. 



3 .6 The Component Existence Function (BL - Oh) 

The Component Existence function returns information about whether a specific 
32-bit BIOS service exists and, if it does, what memory space it occupies. 

Input: 

BL, Oh 

EAX, Component ID 

The Component ID is a 4-byte ASCII string which uniquely 
identifies the 32-bit BIOS service. The specifications for particular 
BIOS services define their own Component IDs. (It is important 
that those specifications define whether the Component ID string is 
packed left to right, or right to left.) 

EBX, Reserved, set to Oh 



02603 .P002 



-6- 



Apper.dix C 



Sttndtrd BIOS 32-bit Service Directory 



Output: 

If requested 32-bit service does not exist 

AL = 81h 
If requested 32-bit service does exist 

AL - Oh 

EBX - base address of 32-bit BIOS service 

ECX = length of 32-bit BIOS service 

EDX = of&et (from EBX) of 32-btt BIOS service entry point 

The meaning of the EBX, ECX, and EDX registers is dependent on 
the particular 32-bit BIOS service specification. That is, they may 
represent exact values for setting up segment selectors, minimal 
"encompassing" values, etc 



3 .7 Future Functions 

Future BIOS32 Service Directory functions may be defined in subsequent revisions 
of this document The function parameter interface is not constrained to register 
passing and may employ input/output parameters on the stack. This is feasible due 
to the static definition of the stack (see Section 0), 

4 Summary 

This paper describes the BIOS32 Service Directory* It identifies 
two distinct memory components: the Header and the Calling Interface. The Header is a 
paragraph of signature data located in the memory range OEOOOOh - OFFFFFL The 
Calling Interface is a body of code that occupies a physically contiguous section of 
memory anywhere in the 4Gb address space and is less than two pages (8kb) in length. 
The Header contains a pointer into the Calling Interface memory area. 

The BIOS 32 Service Directory Calling Interface functions describe additional memory 
areas that contain code and data for specific 32-bit BIOS services. A memory map for a 
hypothetical Header, Calling Interface and the "XYZ" 32-bit BIOS service follows. 
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3 
3 



3 

.3 




3 

.3 





3 



3 



This paper provides for a standard method of accessing 32-bit BIOS 
services. The extensibility of the BIOS32 Service Directory Calling Interface may be used 
easily to advance a standard method as new 32-bit BIOS services are recognized and 
implemented. 
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#ifdef TESTEXEC 
// test bios execute function. 

printf Cphadtest - test bios execution breakpoint^'); 
ioExec = (PIOC_EXECl) systenBuf f er ; 

ioExec->biosFunction » biosShadowArea&aseVA ♦ biosServiceDirector/VA; 
strncpy ( (PUCHAR) (&ioExec->regEAX) , BIOS_PM_SIGNATORE . .4) ; 
ioExec->regEBX = 0L; 

if (DeviceloControHhDriver, 
IOCTL_BIOS_EXEC , 
bufferPtr. 
256, 

bufferPtr, 
256, 

iactualXfr, 

NULL) ) { » . 

printf CIOCTL 2052 -BIOS Execute (%s) - success\n , 

E IOS_PM_SIGNATURE ) ; , v . . v ,_. 

prlncf C# bytes returned: %Ld\n* . actualXfr) ; 

printf ('Register contents : \n* ) ; 

printf CAL * %X\n' , (ioExec->rec;EAX & Oxf f ) ; 

printf CEBX = %LX\n'. ioExec->regEBX ; 

printf CECX = %LX\n". ioExec->regECX ; 

printf CSDX * %LX\n", ioExec->regEDX ); 

)else{ 

ioCode » GetLastErrorO ; . _ . 

printf CIOCTL 2050 failed on %LX\n , loCode) . 

} 

•endif 
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caae IOCTI-_BIOS_QCEC; 

iifdef DEBUGM2 

KxIoKdPrint (4) ; 

tandif 

// Function 4 « Cod* 1052 is 'BIOS Execute' . 

// The function executes cod* La the shadow Area. 

ioExeeBios * (K0C.E3CEC1) ( Irp* > As s oc ia t edlrp. Sy s t emBu f fer) ; 



if (foundBios32 «■ FALSE) * t // if bio«32 not found in. 

ioExecBios->runStat * FALSE? // didn't run. 

return (loCtlFinish (Xrp, STATUS.SUCCESS , sizeof (XOC.EXECD) ); 

} 

// check, the range of the requested function. 

actualXfrd * rangeCheck (ioExecBioa->bios Function. 

1L. 

MODE^SRAOOW , 
lenBiosRoa 

); 

// failed range check, 
if (actualXfrd u 0) ( 

return (XoCtlFinish (Xrp, STATUS.ACCESS.DENIED , sizeof (XOC.EXEcm >: 

) 



// function address. 
// only look at e.p. 
// read/ exec mode, BIOS. 
// length of rom space. 



// now execute the function. 

if ( <ioExecSios->bioaFunction)»« i cui^NG>bios32ServiceEntryPointMULONG> rojnMapPt 

connectBios (ioExeeBios. ioExecflios->biosFunction) ; 
else , 

execfiios (IoExeeBios, toExecBios->bios Function) ; 

ioExeeBios -> runs tat * I; 

return ( IoCtlFinisM Xrp, STATUS .SUCCESS , sizeof (lOC.EXECin ); 
// don't forget to return exec struct.. 
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// this function creates a register context end calls the 
// entry point, 

void 

execflios ( 

M0CJQCEC1 systeabuffer, 
VLOIK entrypoint 

) 

t 

Ufdef BIOS^FAR.CXLL 

void (far *address32) (PIOCJOCEC1) ; 
♦else 

void ('address^! (PXOCJOBCl) ; 
lend if 



*address32 « (void (*) (PIOC^gXECl) )entrypoint; 
_asa ( 

mev eax, tsysteabuf f erl // ptr to the systembuffer 
push eax // 

push cs // entice it a FXR call 

call Ceddxess32] // call to the Serive Directory 



// (*address32) (syetembuffer) ; // this is service interface. 

> 
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